UWP Serial Port Missing Bytes, Bytes Written Windows IoT

Whilst writing a PCX format, 1 bit per pixel (1bpp) byte array to a serial port FTDI USB serial adapter using WinRT/UWP, on a Laptop (using for developing before deploying to RPi2), it kept failing to work correctly. The serial port was going to the RS232 input of a Zebra Thermal printer, the PCX representing a bitmap to print. The code below was used to push the byte array through to the serial port, after failing to find any answers on line and eliminating other possibilities, a logic analyser on the serial port uncovered the issue. The bye array was not complete.  

public async Task Print(byte[] bytesTosend)
using (DataWriter dataWriteObject = new DataWriter(serialPort.OutputStream))
await WriteBytesAsync(dataWriteObject, bytesTosend);
if (dataWriteObject != null)

public async Task WriteBytesAsync(DataWriter dataWriteObject, byte[] bytesTosend)
Task<UInt32> storeAsyncTask;
int offset = 0;
int buffersize = bytesTosend.Length;
//if (buffersize > 1000) { buffersize = 1000; }
byte[] sendBuffer = new byte[buffersize];
System.Buffer.BlockCopy(bytesTosend, offset, sendBuffer, 0, buffersize);
storeAsyncTask = dataWriteObject.StoreAsync().AsTask();
UInt32 bytesWritten = await storeAsyncTask;
offset += buffersize;
} while (offset < bytesTosend.Length);

Running the code in debug and looking at the length of the byte array, compared to the bytes sent, the problem is clear to see. The image is 200x200 pixels, so at 1bpp this is 200/8 bytes wide * 200 rows = 5000 bytes.

Indeed the byte array is 5000 bytes to send, but wait look at how many bytes have actually been sent, 4096 bytes! Somewhere four bytes have gone missing, thus the printer is awaiting the complete image and does not print.

 Byte writing code showing the debug values

There seems to be no way to flush the buffer or any other methods on the DataWriter that could be used to force these extra bytes out, anyway the missing bytes might not necessarily from the end of the array. There is a FlushAsync method, however that returns a “not implemented” exception – gotta love coding on this platform…

So perhaps by gut says this is actually some kind of serial buffer overflow problem. Some support to this theory is that writing low numbers of bytes to the serial port works just fine.


Fixing serial port write on UWP application missing bytes

MakerFaire is in three weeks time so a solution is needed quick, not time to raise with Microsoft. As smaller writes works, and my suspicion is a buffer overflow, the solution is to uncomment the commented out line in the code above. This will break any byte array larger than one thousand bytes into chunks and send them one chunk at a time.

Running the code worked, printing the image perfectly every time.

This seems to be how it is in the world of Windows IoT and UWP at the moment, if feels like the first couple of years of the first versions of .NET all over again!

Serial Port null from SerialDevice.FromIdAsync(dis[0].Id) with windows UWP & FTDI adapter

Whilst on a laptop the following code fails whereas it is working on the RPi2. The serial port is provided by a USB to serial adapter, a USB FTDI adapter.
var aqsFilter = SerialDevice.GetDeviceSelector();
var dis = await DeviceInformation.FindAllAsync(aqsFilter);
serialPort = await SerialDevice.FromIdAsync(dis[0].Id);
serialPort is null when a break point is put after the last line, but is correct when running the RPi2.
I updated the driver in device manager for the adapter, but it still failed. After following several other posts on the internet and failing I then, after an hour or so discovered the following stack overflow post:
The key was to also update the USB Serial Converter as well as the COM driver. Do this by uninstalling the driver after right clicking it. Make certain that  the check box is selected to delete the driver.
USB Serial Converter
Scan for hardware changes will then install an updated driver that allows the serial port to be found by ID.
So running the original code it now finds the serial port as expected.


Note the missing SPI1 on the new revision of the Windows IoT pinouts for Raspberry Pi


It seems the SPI1 (pins11,35,38,40/GPIO 19,20,21,17) have been assigned to GPIO on the latest pin out.

Apparently there are five alternatives for the use of the pins, see:http://elinux.org/RPi_BCM2835_GPIOs

Only two SPI devices seems quite constrained when I’m used to .NET Microframework on the Netduino where such constraints are not present.

Next the sample push button application has been updated from using polling to using interrupts, get the feeling that the sand is moving under my feet with Windows IoT.

Windows IoT Core 10 & Raspberry Pi missing Gpio reference

Error CS0246 The type or namespace name 'GpioPin' could not be found (are you missing a using directive or an assembly reference?)

Problem that you don't appear to be able to have the Gpio namespace or spi namespace or I2C namespace in your project?

Started looking at the Samples for Windows IoT on the Raspberry Pi, say from the samples Github https://github.com/ms-iot/samples or perhaps from the accompanying https://microsoft.hackster.io/en-US examples?

Working with Win IoT is tricky at the moment as it’s early days for the platform, thus much of the information out there is already out of date as it originates from the previews, after which the landscape has matured. In the next blog post I will highlight how the pin-outs on the Raspberry Pi have changed, the SPI1 is not longer present on the Windows IoT Raspberry Pi API. The graphic on the FAQ has been updated, making all the links to it from forum posts and similar, where the graphic has been linked, not make sense anymore with the new graphic. This is merely one of the many examples where you have to tread carefully and have faith in your experience and knowledge. Having worked extensively with the .NET Microframework on the Netduio platform has given me valuable experience to apply to the new Win IoT world.

When following any of the examples on line, or indeed starting a new project for the first time, there is one important piece of information that is missing. The fact that a reference the “Windows IoT Extensions for the UWP” is required to get the hardware namespaces. This makes perfect sense when you stop to think for a moment. This .dll adds to the UWP the namespaces required for access to hardware features of  IoT devices like the raspberry Pi.


This includes Gpio, Adc, I2c, Pwn, Spi namespaces for Windows IoT Raspberry Pi.

Add a reference to Windows IoT Extensions for the UWP and Windows.Devices.Gpio will become available in intellisence.


Windows IoT Extensions for the UWP

So the references work in similar way to the .NET Microframework where for the Netduino the following references would be normally added to access the hardware, and other references used if one of the alternative platform boards was used: