Microsoft MVP Azure | IoT Platform Architect | Speaker about IoT | Let me add some value
If you only have a hammer, everything looks like a nail. And my biggest hammer for now is Firmata.
I was looking at an Ignite 2015 presentation, MOB324, where a kind of radar using a distance reader was demonstrated. And at the same time I was checking out the same usage of a distance reader and a servo as part of am Arduino controlled car.
So I tried to do the same using Firmata. And it’s pretty easy, with a little twist.
But first we look at the servo part using the Arduino Servo.h library.
If you managed to get to this part, you have seen how simple wired communication protocol between two Arduino’s is transformed into communication over Bluetooth using the Firmata protocol. Great!
Now we take a look, again, at a demo given at the Ignite 2015 in Australia. In this demo, an ultrasonic distance reader is used to generate a custom stream of measurement.
Although it’s a demo and it serves a purpose, the solution shown has an architectural flaw. If we look deeper into the Arduino code, we will find a ‘while (true) {}’. It is put inside a switch inside the ‘custom function handler’ sysexCallback().
Yes, this generates a constant stream of measurement but it also locks up the Firmata on the Arduino. No other call will de handle anymore because the endless loop is just blocking further communication.
Doorgaan met het lezen van “Better long running custom Firmata functions”
In my previous blog, we investigated the usage of the standard Firmata protocol to communicate between UWP apps and an Arduino. I ended with directing to Channel 9 for more information about custom functions in Firmata.
But I think that’s not enough 🙂 First of all, that demo in the presentation failed. And next to that, it simply lacked any description on how to do it yourself.
I have put some time in figuring out this functionality. Again, the example below is based on the code of Part 4.
So we want to call some logic on the Arduino, using Firmata, and it has to be available for real-time usage. So we want to pass some parameters and we want to receive some response.
Doorgaan met het lezen van “Custom Firmata function called by Windows 10 IoT Core”
This is part 4 of a series of blogs about device communication between Arduino, RaspberryPi etc:
I have shown in my previous post that it’s fairly easy to control an Arduino over Bluetooth.
This was done using a ‘custom’ protocol. I sent an integer value to let a LED blink that number of times on the Arduino.
But designing your own protocol is not always that easy. And I can recommend using industry-wide accepted protocols if available.
One of them is Firmata.
“Firmata is a protocol for communicating with microcontrollers from software on a computer (or smartphone/tablet, etc). The protocol can be implemented in firmware on any microcontroller architecture as well as software on any computer software package”
This sounds promising, doesn’t it?
Using Firmata, it should be possible to access the ports on the Arduino directly from a UWP app, without extra custom code needed on the Arduino.
Of course, we NEED code on the Arduino, but that’s just a standard sketch, which is available in the examples library inside the Arduino IDE.
I just downloaded the latest version (now 2.5.1) of the Firmata Arduino library from the GIT repository because it was not yet available in the IDE. That’s why it is just in another place in the menu. Select the StandardFirmata sketch:
The Firmata protocol supports a connection between the UWP app and the Arduino using USB, Bluetooth and Wifi. In this example, we will use Bluetooth. There is one caveat, the baud rate used to communicate can vary with the board you use (it’s all about quality). Initially, it’s 57600 baud. I changed it into 9600 baud, just to make sure the communication speed will not be an issue.
Upload the sketch. Plug in your Bluetooth module on port 0 and 1 (cross the RX and DX lines). That’s all we need to do on the Arduino.
Just to check if everything is working, Microsoft already provides a nice app. Download the Windows Remote Arduino Experience for free, just to test your Firmata sketch.
If your Arduino is connected to your PC using USB, first try to talk to it using the USB connection. Here I have selected the Bluetooth module (and I selected the correct baud rate, equal to the rate in the sketch):
Either way, USB or Bluetooth, the outcome should be the same. The (digital) pin layout should be shown:
Now activate output pin 13. This is the standard available LED op the Arduino board. This LED should be lit. And yes, this also works on my Windows Phone:
Note: I got this message “Pin configuration not received” the first times I tried to connect to my Arduino using Bluetooth:
If you get this message, just check the serial port connection (pin 0 and 1) and the baud rate in the sketch.
So now we will do the same communication in our own UWP app.
Start a new UWP template. Add the Bluetooth capability to the list of capabilities in the Package.appxmanifest.
To communicate to a Firmata device, we also need the NuGet package called “Windows-Remote-Arduino”:
Our main page needs the following controls:
<StackPanel> <Button Name="btnList" Click="btnList_Click" FontSize="20" Content="List" /> <Button Name="btnStart" Click="btnStart_Click" FontSize ="20" Content="Start" /> <Button Name="btnOn" Click="btnOn_Click" FontSize="20" Content="Led On" IsEnabled="False" /> <Button Name="btnOff" Click="btnOff_Click" FontSize="20" Content="Led Off" IsEnabled="False" /> </StackPanel>
And we need the following code-behind:
public sealed partial class MainPage : Page
{
private BluetoothSerial _bluetooth;
private RemoteDevice _arduino;
public MainPage()
{
this.InitializeComponent();
}
private async void btnList_Click(object sender,
RoutedEventArgs e)
{
var a = await BluetoothSerial.
listAvailableDevicesAsync();
var b = a.First();
var c = a.First(x => x.Name == "HC-05");
var d = b.Name;
}
private void btnStart_Click(object sender,
RoutedEventArgs e)
{
_bluetooth = new BluetoothSerial("HC-05");
_arduino = new RemoteDevice(_bluetooth);
_bluetooth.ConnectionLost +=
_bluetooth_ConnectionLost;
_bluetooth.ConnectionFailed +=
_bluetooth_ConnectionFailed;
_bluetooth.ConnectionEstablished +=
OnConnectionEstablished;
_bluetooth.begin(0, SerialConfig.SERIAL_8N1);
}
private void _bluetooth_ConnectionLost(string message)
{
throw new NotImplementedException();
}
private void _bluetooth_ConnectionFailed(string message)
{
throw new NotImplementedException();
}
private void OnConnectionEstablished()
{
var action = Dispatcher.RunAsync(
CoreDispatcherPriority.Normal,
new DispatchedHandler(() =>
{
btnOn.IsEnabled = true;
btnOff.IsEnabled = false;
}));
}
private void btnOn_Click(object sender, RoutedEventArgs e)
{
//turn the LED, connected to pin 13, ON
_arduino.digitalWrite(13, PinState.HIGH);
var action = Dispatcher.RunAsync(
CoreDispatcherPriority.Normal,
new DispatchedHandler(() =>
{
btnOn.IsEnabled = false;
btnOff.IsEnabled = true;
}));
}
private void btnOff_Click(object sender, RoutedEventArgs e)
{
//turn the LED connected to pin 13 OFF
_arduino.digitalWrite(13, PinState.LOW);
var action = Dispatcher.RunAsync(
CoreDispatcherPriority.Normal,
new DispatchedHandler(() =>
{
btnOn.IsEnabled = true;
btnOff.IsEnabled = false;
}));
}
}
First of all, we have to connect to the Bluetooth module. I added placeholder code for the ConnectionLost en ConnectionFailed events. Just so you can act on these circumstances (in case you get the name of the device wrong).
Note that the baud rate is set to 0 (zero). It just works 🙂
When the Bluetooth connection is up, the On button becomes available. Look at the code, we can write LOW or HIGH to digital ports. So we write to the output port 13. The LED on the board will be lit or unlit:
The Arduino class also supports reading and writing to analog ports. And I2C communication seems to be possible too.
Letting the LED blink several times, as in the previous blog post, is now trivial. It can be programmed just in C#.
The drawback of Firmata is that the real-time behavior of the Arduino is now limited by the speed of the calling UWP and the speed of the communication. And complex communication with exotic modules over several pins with specific timing will be hard or even impossible.
So if you need real-time interaction and still want to use Firmata, take a look at the Ignite presentation Windows IoT, UWP and the Remote Wiring API by Mitch Denny. He adds custom code to the Firmata sketch and executes it by name. Then he listens for the response which is received using an event handler. It acts just like a stored procedure in a database.
Update: The source code of the Windows Remote Arduino Experience app is available at GitHub.
This is part 3 of a series of blogs about device communication between Arduino, RaspberryPi etc:
In previous blogs, I have written about combining one or more Arduino Nano’s with a RaspberryPi using the I2C protocol. Although this is very useful, the communication is limited to the length of the cables. This is not very practical for a local gateway.
 |
 |
So I looked at communication using Bluetooth. So I bought some Bluetooth modules. These little components are relatively cheap and reliable. They come with four and six pins (for now, it has just two extra pins not needed, the inner four are the same with the four pins version) but the four pin variant is used in this example.
Doorgaan met het lezen van “Use Bluetooth between Win 10 UWP and Arduino”
Working with a Raspberry Pi is fun. Working with Windows 10 IoT Core is even more fun, combined with that Rpi. But it’s a bit annoying that we have to drag a big LCD monitor along when we want to do some visual XAML stuff on it.
Should it not be nice to use one of those tiny LCD screens on your Rpi? You can buy them for approx. 25 dollars so these are really interesting. They have HDMI, they are powered by USB and it’s even possible to put some touch to them 🙂
So I ordered one. It came in a nice package and connecting it to the Rpi was easy, just connect an HDMI cable and plug in the micro USB connector for power.
|
|
But then I got scared, this is what was shown on the screen:
It should be clear that the vertical black bar was not to be shown there!
After the Shock or Disbelief, the Denial, the Anger, etc. there was Acceptance and Hope. A good friend pointed out that the Rpi could use some configuration to handle these small screen resolutions.
So I looked at the config.txt which can be found in the root of the image on the MicroSD card on the Rpi.
gpu_mem=32 # set ARM to 480Mb DRAM, VC to 32Mb DRAM framebuffer_ignore_alpha=1 # Ignore the alpha channel for Windows. framebuffer_swap=1 # Set the frame buffer to be Windows BGR compatible. disable_overscan=1 # Disable overscan init_uart_clock=16000000 # Set UART clock to 16Mhz hdmi_group=2 # Use VESA Display Mode Timing over CEA arm_freq=900 arm_freq_min=900 force_turbo=1
Note: ignore wrapping if shown. Comments should only fill one line. Just compare it with your own config.txt
So after some searching, I found the resolution:
... hdmi_group=2 # Use VESA Display Mode Timing over CEA hdmi_mode=1 # 5 inch screen hdmi_mode=87 # 5 inch screen hdmi_cvt 800 480 60 6 0 0 0 # 5 inch screen ...
Just add these extra three lines and you are back in business. You can just do that on your laptop the same way as you created the image: using an SD card adapter.
Note: make a backup first!
Now look at this screen:
As you can see we even have a scrollbar.
So now you have a small transportable screen which works just fine when you are developing for Windows 10 IoT Core.
Pro tip
If you are a Raspbian or Raspbian Jessie light user, this will work for you took. Just open /boot/config.txt and add the same four lines. And reboot afterwards.
Sander van de Velde 