Having managed to do a GCC port of OSHW to Discovery4 (no crystal change) Thanks again to NicolasG, I was doing some debugging of serial ports.
I noticed that it took 10-15 seconds to expand a Port object in the Locals or Watch window. It made debugging very frustrating as the system is locked until is updates the screen.
I presumed it was because I was GCC. So I tried the same program on my Panda (love that old thing). It also took 10-15 seconds as well so not that.
I then tested my Discovery4 with the Oberon port. That takes about 2 seconds for the same thing.
Is this a USB Debugging interface driver issue?
An extract of the relevant code. I set a breakpoint at the while (true), type into the serial window and then try to expand UART1 in the locals window.
SerialPort UART1 = new SerialPort("COM1", 115200);
SerialPort UART2 = new SerialPort("COM2", 115200);
int read_count = 0;
byte[] rx_byte = new byte[1];
UART1.Open();
UART2.Open();
while (true)
{
// read one byte
read_count = UART1.Read(rx_byte, 0, 1);
if (read_count > 0)// do we have data?
{
// create a string
string counter_string =
"You typed: " + rx_byte[0].ToString() + "\r\n";
// convert the string to bytes
byte[] buffer = Encoding.UTF8.GetBytes(counter_string);
// send the bytes on the serial port
UART1.Write(buffer, 0, buffer.Length);
UART2.Write(buffer, 0, buffer.Length);
//wait...
Thread.Sleep(10);
}
I noticed the same thing: debugger memory display is really slow, no matter the type involved.
It’s nice to see it can be improved.
I think the difference is the USB driver.
What is the USB driver used by Oberon?
That was my suspicion but I really am not skilled enough to say.
I don’t know the details of the debugging in the Oberon port. As to the USB driver they provide them on their codeplex site described as STM32_WinUSB_drivers_(for_evaluation_purposes_only).
I will have to look at the 2 PK solutions to see.
Getting a bit beyond by skill and understanding - but maybe get time at the weekend
Would you believe, but it was as simple changing one 1 file. I now have the 2 second response in debugging!
Change this file: [quote]C:\MicroFrameworkPK_v4_3\Solutions\FEZCerberus\DeviceCode\USB\usb_config.cpp[/quote]
for the Oberon version you can find in their source for Discovery4
recompile and fast debugging. You will need their drivers installed of course. But what a difference.
I imagine, but don’t know, but that might work for the Spider too. Let us know Andre if it does.
We had issues with latest code we tested from Oberon. Not sure what it was and not sure current code is different. Either way, this is still on our to check list. Just a FYI
Rajesh I think you’re right.
Gus the Oberon PK source and WIN USB drivers are the ones from their August 2012 download on Codeplex.
I have no idea what the difference is between Oberon and GHI on the Windows driver side. (I have a solution I can live with now)
All I can say is using the same USB port, same STM32F4DISCOVERY with the same firmware, bar the usb_config.cpp file, which simply permits the Oberon Windows driver to be used, the wait time goes from 10-15 seconds to 2 seconds.
I found the answer.
The USB driver is installed for a specific ProductId.
There are 2 GHI drivers,
Legacy for PID 0x0102 : C:\Program Files (x86)\GHI Electronics\GHI Premium NETMF v4.2 SDK\USB Drivers\GHI Legacy Drivers\GHI_NETMF_Interface.inf
WinUSB for PID 0x0106 : C:\Program Files (x86)\GHI Electronics\GHI Premium NETMF v4.2 SDK\USB Drivers\GHI_NETMF_Interface\ghi_netmf_winusb.inf
As everyone knows now, WinUSB is far better.
Cerb-Family official firmware uses PID 0x0106
In the open source on codeplex (usb_config.cpp), the PID is set to 0x0102 and then the debug port is handled by legacy driver…
// device descriptor
#define VENDOR_ID 0x1B9F
#define PRODUCT_ID 0x0102 // 0x0106 <--- For new PID // 0x0102 <--- Old debugger Product ID