The debugging example on mbed.org doesn’t work for me…
#include "mbed.h"
Serial pc(USBTX, USBRX); // tx, rx
int main() {
pc.printf("Doesn't work!\n");
}
This version does though.
#include "mbed.h"
#include "USBSerial.h"
//Virtual serial port over USB
USBSerial serial;
int main(void) {
while(1)
{
serial.printf("This works!!!\n");
}
}
The 2nd code produces the behavior you’d expect. Printing to the virtual com port (COM5 for me). My system Windows 7 - 64 bit.
@ Dr9 - Did you have to install the Windows Serial Port driver for mBed? Or does the code below work without that?
I wasn’t able to get the driver to install on my Windows 8.1 laptop, though I’ve seen posts from others in the mBed forums that have gotten it to install and work.
May have to try on another machine, to see if I can get the driver install to work.
The instructions aren’t super-clear, either…they say that you shouldn’t have an explorer window open when attempting to install the drivers, but it’s not clear if that means the board should be in run mode, or in loader mode and close the window that opens when you enter loader mode. Do you recall which way worked for you?
@ Dr9 - USBSerial takes care of creating a Virtual Serial Port that is recognized when you plug in the device to the PC. To use Serial you need an external USB to Serial adapter that you can connect to the pins you have passed to the Serial object.
Also, unless software UART is supported, you can only use UART pins with Serial object.
@ devhammer - Try to instantiate USBSerial in your code and print something to it. The virtual com port appears in Device Manager only when you have a valid USBSerial object.
I believe I got the drivers to load in run mode - after a long delay. Otherwise if you try and run the driver craps out with ‘No mbed Microcontrollers were found’.
No luck. If I have the include and instantiation for USBSerial, it does not appear that my program runs at all (I combined with the default LED blinking code as a test). If I comment out the instantiation code, the blinky code runs fine, but if the USBSerial code is there, the LEDs do not blink.
Also, when in run mode, I get a “CDC DEVICE” in the Devices and Printers window with a yellow bang indicating that no driver is installed. If I uninstall the device, and unplug/plug the USB cable, Windows shows the driver install dialog, but no driver is installed.
@ Dr9:
Thanks for the pointer to the INF file. I’ll have to try that the next time I reboot. Unfortunately, Windows 8.1 won’t let me install the inf because it’s not digitally signed.
@ Dr9 - Just tested the INF file on my Windows 10 Tech Preview machine, and the mBuino now shows up as a COM port. w00t!
Even better, it looks like Windows 10 has gone back to the model of prompting (with a scary red color in the dialog) when installing unsigned drivers, rather than preventing them unless you disable the feature in the advanced startup settings.
While I agree with Microsoft making it hard to install unsigned drivers as a means of protecting end-users, having to reboot to disable this in Windows 8/8.1 is a big pain…good move to make this easier. Just hope that makes it to the final version of Windows 10.
@ Dr9 - Another question…is the INF effectively a replacement for the executable driver installer? Or a prerequisite?
On my Win10 machine, the test program seems to be running fine after installing the INF, but when I tried installing the executable driver installer, it still complains that it can’t find an mBed microcontroller.
Downloading teraterm now to see if the board is outputting to the com port as expected.
Thanks to @ Dr9, I’ve got USB serial output working on my Windows 10 machine. Assuming I can get the INF installed on my Win81 laptop, I should be good to go.
@ Dr9: as noted in this topic and as noted in #4 by @ Architect, the naming of USBRX and USBTX seems to be misleading on mBuino. They are defined as pins 19 and 18 and appear not connected to the mini-usb port, for which I’m using the USBSerial class.
Have you tried connecting a USB-to-Serial plug such as the Prolific to pins 19 and 18?
In my testing I’m using the USBSerial for debugging and I got a simultaneous (mostly) successful Serial connection to an ESP8266 module using pins 19 and 18.
I’m now struggling to get my uSD-adapter working via the SPI pins. As it looks now I’m afraid that I will need to use that USBSerial debugging port more than I wished for…
Tip for others using USBSerial for debugging: I use Putty as serial console. Whenever the connection is terminated I need to restart the Putty window. This has to be done [em]after[/em] mBuino was reset to run-mode.
Thanks to your INF, I’ve now got USB serial working on my Windows 8.1 laptop. Just had to go through the “disable driver verification” at startup routine, and the INF installed fine. Plug in the mBuino, and BOOM, virtual serial port.
Downloaded PuTTY, and all is well.
This will definitely make for somewhat easier debugging.
In case anyone else might find it useful, here’s some test code that combines the default LED pattern for the stock mBuino firmware with some serial debug code that writes out the current color of the LED that should be lit:
#include "mbed.h"
#include "USBSerial.h"
//Virtual serial port over USB
USBSerial serial;
DigitalOut LED[] = {(P0_7), (P0_8), (P0_2), (P0_20), (P1_19), (P0_17), (P0_23)};// declare 7 LEDs
float delayTime = .05;
void debugOutput ( int x )
{
switch (x)
{
case 0:
serial.printf("Red!\r\n");
break;
case 1:
serial.printf("Orange!\r\n");
break;
case 2:
serial.printf("Yellow!\r\n");
break;
case 3:
serial.printf("Green!\r\n");
break;
case 4:
serial.printf("Yellow!\r\n");
break;
case 5:
serial.printf("Orange!\r\n");
break;
case 6:
serial.printf("Red!\r\n");
break;
}
return;
}
int main()
{
while(1)
{
//serial.printf("This works!!!\r\n");
delayTime = 0.05;
for(int x = 0; x < 7; x++)
{
debugOutput ( x );
LED[x] = 1; // turn on
wait(.2); // delay
LED[x] = 0; // turn off
wait(delayTime); // delay
}
for(int x = 5; x >= 0; x--)
{
debugOutput ( x );
LED[x] = 1; // turn on
wait(.2); // delay
LED[x] = 0; // turn off
wait(delayTime); // delay
}
for(int x = 0; x < 7; x++)
{
debugOutput ( x );
LED[x] = 1; // turn on
wait(delayTime); // delay
}
for(int x = 6; x >= 0; x--)
{
LED[x] = 0; // turn off
wait(delayTime); // delay
}
}
}
Given my newbness with C++ and mBed, any feedback on improving the code is welcome.
In the board support files there are a set of #defines for the LEDs
e.g.
So rather than
```cpp]DigitalOut LED[
= {(P0_7), (P0_8), (P0_2), (P0_20), (P1_19), (P0_17), (P0_23)};
you could have
functionally identical but a little nicer to look at and is a more portable between platforms (not that any others have 7 LEDs but at least you'll get a compile error rather than changing random GPIO lines).
Secondly mBed has a BusOut class that you could use instead. Very little downside but lets ou set all the values without having to loop through the array.
```cpp
BusOut LED(LED1, LED2, LED3, LED4, LED5, LED6, LED7);
LED[x] = 1; // works the same as for an array of DigitalOut;
LED = 1<<x; // sets bit x high and all other bits low.
LED = 0x15; // sets bits 1,3 and 5 high, others low. 0x15 = 001_0101
Due to the way it’s defined LED++; and LED += 1; don’t work but LED = LED + 1; does.
Also your switch statement could be shortened and should technically have a default (come compilers don’t mind this, some complain about it):
switch (x) {
case 0:
case 6:
serial.printf("Red!\r\n");
break;
case 1:
case 5:
serial.printf("Orange!\r\n");
break;
...
default:
serial.printf("That's not an LED!\r\n");
break;
}
@ AndyA - BusOut mostly works for me, but not with the LED[x] = 1; syntax. If I try to keep that syntax, the mBed compiler throws the error:
Error: No operator “[]” matches these operands in “main.cpp”, Line: 65, Col: 16
If I use the LED = 1<<x; (and 0<<x to turn off) syntax, it works, but changes how the last two loops work (previously, they’d turn on all the LEDs in order, then turn them off in reverse order).
If I use the DigitalOut syntax with the LED1, etc. syntax, that works fine with LED[x] = 1;
