There are currently 2 reserved GPIO pins on the RPI2 that ordinarily are SOC (I call native) serial. A future Tx and Rx but not at the moment. Serial is achieved on the RPI2 with Win 10 IoT Core via a USB-Serial device connected to a Host USB port on the RPI2. There are though limitations in that the widely used FTDI chipset is not supported by Microsoft, although we have a solution. An alternative is over Bluetooth but there is an issue there.
Update 21 Oct 15: Native Serial on Pins 8 and 10 is now available: Win 10 IoT Core: Raspberry PI 2 Native Serial is Live!
Win 10 IoT Core: Raspberry Pi 2 Peripherals – Introduction
Win 10 IoT Core: Raspberry Pi 2 Peripherals - Connected Devices
Win 10 IoT Core: Raspberry Pi 2 Peripherals - Connected Devices (Code)
Win 10 IoT Core: Raspberry Pi 2 Peripherals - Connected Devices: USB HID Peripherals
Win 10 IoT Core: Raspberry Pi 2 Peripherals – Serial <This page>
<ToDo> Win 10 IoT Core: Raspberry Pi 2 Peripherals – My list of working/not working USB devices
<ToDo> Win 10 IoT Core: Raspberry Pi 2 Peripherals – USB Ethernet & WiFi
<ToDo> Win 10 IoT Core: Raspberry Pi 2 Peripherals – USB Bluetooth
<ToD0> Win 10 IoT Core: Raspberry Pi 2 Peripherals – USB Storage
<ToDo> Win 10 IoT Core: Raspberry Pi 2 Peripherals – USB Audio & Web Cam
<ToDo> Win 10 IoT Core: Raspberry Pi 2 Peripherals – Off-the-shelf USB devices
Whilst the MInnowBoardMax has an onboard UART, the driver fro the Raspberry PI 2 UART is not yet supported with Windows 10 IOTCore. The absence of a native serial port for the RPI2 is probably an Achilles Heal for this platform.
This leaves USB-Serial as the main conduit for implementing serial with the RPI2.
I tested the CP2102EK USB-UART Bridge Evaluation Kit. Initially the C# version of the test app (see Coding below) failed to load the driver. I tested the eval kit with the test app on my desktop where it worked, as did the CPP version. I then tested the CPP on the RPI2 which worked after which the C# version worked on the RPI2?? (I am logging this here in case anyone else has a similar situation.) The initial problem might have been because I initially tried an earlier version of the app. But of well I can report that the CP2102EK USB-UART Bridge does work on the RPI2 out of the box with a Universal Windows “generic” serial app.
http://www.freetronics.com.au/products/usb-serial-adapter#.VhZbvY0VhMs
This uses the ATMEGA16U2.
I haven’t tested this.
See FTDI Chipset below.
See Arduino below.
See Bluetooth below
Another (non USB) alternative would be to use the RPI2 SPI or I2C bus using a SPI/I2C to RS232 interface board.
Some examples are (haven’t tried them):
Whilst the Universal Windows async device coding can be very slick and elegant but look like “spaghetti code” when you try to debug t (have a look at the Arduino Remote Wiring code) in this case it doesn’t have to be. You no longer open a COM port like a file as one did with native code. You query the Serial class for a list of connected serial devices. You then select a device and get the device information and use this to connect to the device. A more complex example will run a watcher that that fires an event when a serial device is connected (via USB Host) which updates the list.
App creation starts by creating a Windows 10 Universal Windows app (Blank template).
You do not need the IoT extensions as this is a truly Universal app. The same app can be compiled for the desktop (x86 or x64) and compiled without modification for IoT –Core.
You need to set the app as have serial port capability. Text edit the Package.appmanifest file and add (There will be a internetClient capability by default):
<Capabilities> <Capability Name="internetClient" /> <DeviceCapability Name="serialcommunication"> <Device Id="any"> <Function Type="name:serialPort" /> </Device> </DeviceCapability> </Capabilities>
Whilst writing to the port is simple, the coding has changed a little from the RTC version of the sample. I found with that that you needed a button press to explicitly action a read. With the RTM sample you perform await ReadAsync() in the loop which permits the rest of the UI to continue unblocked whist the device is awaiting serial input to read.
There is a test application on GitHub at: https://github.com/ms-iot/samples/tree/develop/SerialSample/This is discussed at: Sample Serial app
When the app run you get a list of connected devices. The device VID/PID’s are displayed.You select one and can then read and write data. For testing I typically use a loopback adapter (9 pin, Tx connected to Rx)
As indicated, there is demand for an FTDI device driver with the RPI2 but its not currently supported by Microsoft. FTDI created a Windows ARM driver for the RT Surface. A methodology and some sample apps have been documented using this on the RPI2. Currently this only works for Universal Windows Apps. and doesn’t work for Headless Startup Tasks. We are currently looking into that.
Links:
My last blog on the issue has a link to all of this: Win 10 IoT Core- FTDI Serial Driver–Headless Startup Task problem
FTDISimpleIoT on GitHub: https://github.com/djaus2/FTDISimpleIoT (My simplified version .. NEW).
Previous blog on topic: http://embedded101.com/Blogs/David-Jones/entryid/666/win-10-iot-core-ftdi-serial-driver
FTDI D2XX Drivers: http://www.ftdichip.com/Drivers/D2XX.htm (They are in the GitHub project). Look for | Windows RT | 2014-07-04 | .. the second line in the table.
D2xx WinRT Guide: http://www.ftdichip.com/Support/Documents/InstallGuides/AN_271%20D2xx%20WinRT%20Guide.pdf
Jark’s Project on GitHub: https://github.com/Jark/FTDISample
The FTDI API is straight forward. You code using async coding techniques (see FTDISimpleIoT on GitHub link above):
Jark (see Jark’s Project on GitHub link above) makes a good point in his code that you might have to wait awhile after the manager is instantiated before anything appears in the list. Hence run the second step repeatedly via a timer until the list is populated. Jark’s app on GitHub (FTDISample) is a well structured Universal Windows app. Mine (FTDISimpleIoT) is just a quick-a-dirty one for testing, It also has a Startup Task project.
You have to add specific capabilities to the app for the VID/PISs of the FTDI devices that can connect:
<Capabilities> <Capability Name="internetClient" /> <DeviceCapability Name="usb"> <!--FT232AM, FT232BM, FT232R and FT245R Devices--> <Device Id="vidpid:0403 6001"> <Function Type="name:vendorSpecific" /> </Device> <!--FT2232D and FT2232H Devices--> <Device Id="vidpid:0403 6010"> <Function Type="name:vendorSpecific" /> </Device> <!--FT4232H Device--> <Device Id="vidpid:0403 6011"> <Function Type="name:vendorSpecific" /> </Device> <!--FT232H Device--> <Device Id="vidpid:0403 6014"> <Function Type="name:vendorSpecific" /> </Device> <!--FT-X-Series Devices--> <Device Id="vidpid:0403 6015"> <Function Type="name:vendorSpecific" /> </Device> <!--My Custom Device--> <!--<Device Id="vidpid:1234 4321"> <Function Type="name:vendorSpecific" /> </Device>--> </DeviceCapability> </Capabilities>
The term out-of-the-box was used previously in this blog. This vendor specific device information above is an example of some not out-of-the-box.
Arduino devices have a USB-Serial port that is typically used to program the device and becomes the default serial port when a sketch (app) runs on it. If the Arduino device is programmed, and has applications comms over that port, then you can run a cable from the Arduino micro USB to a Raspberry PI 2 USB Host port. The RPI2 then will fire up a a serial port which apps such as the sample app above can use. There was a a catch with the IoT Core RTM OS. I found that this serial port works fine wit the Arduino Uno (I actually used the Freetronics EtherTen, a Uno compatible device.) In the RTM documentation the recommended Arduino device for which the USB-Serial works was the Arduino Leonard. I find that with the same Arduino sketch loaded on both Arduino devices, with serial reads and writes, you can write to the Uno and Leonardo but can only read from the Uno. This has been accepted as bug by Microsoft and they have put it on their ToDo list.
For my Leonard device I used the DFRobot Arduino Expansion Shield for Raspberry Pi My attraction to this was it plugs directly to the top of the RPI2 and communications between the two can be by UART on both ends (not possible at the moment on the RPI2 end of course!). So for the moment I have to make do with the USB-Serial connection but that doesn’t work properly so I just use my EtherTen for the moment.
Of interest is the ability to run the Arduino IDE on the Linux version of the RPI2 OS and directly program the attached Arduino device. Future activity??
For this activity I added the Freetronics LCD & Keypad Shield to the Arduino device. It has 2 lines x 16 characters of text plus. Its features are:
I developed a sketch on the Arduino device that provides a menu for the RPI2 over the serial port. The keypad buttons permit you to navigate up and down through lines of menu buttons and to navigate left and right through them on a line. You then use the fifth (Select) button to select the chosen menu item:
<Watch this space>
Another option is to use a Bluetooth-Serial device. The problem at the moment is that Windows 10 IoT Core does not Pop-Up, ie Message Boxes so the use of Passkeys when pairing Bluetooth devices is an issue. This will be covered in a later blog in this series on Bluetooth.