Has anyone successfully used the USB Serial module

Poncho · November 14, 2011, 4:25pm

Hello,

I have been trying to use the USB Serial module to send data over USB to another computer but have failed at the first hurdle.

Anytime I try and deploy any code which makes reference to the Usb Serial module it doesn’t deploy citing garbage collection errors as below:

Using mainboard GHIElectronics-FEZSpider version 1.0
GC: 1145msec 13008888 bytes used, 32160 bytes available
Type 0F (STRING              ):   1416 bytes
Type 11 (CLASS               ):  11400 bytes
Type 12 (VALUETYPE           ):   1476 bytes
Type 13 (SZARRAY             ):   4380 bytes
Type 15 (FREEBLOCK           ):  32160 bytes
Type 16 (CACHEDBLOCK         ):     72 bytes
Type 17 (ASSEMBLY            ):  29160 bytes
Type 18 (WEAKCLASS           ):    192 bytes
Type 19 (REFLECTION          ):    168 bytes
Type 1B (DELEGATE_HEAD       ):    756 bytes
Type 1D (OBJECT_TO_EVENT     ):    216 bytes
Type 1E (BINARY_BLOB_HEAD    ):    192 bytes
Type 1F (THREAD              ):    768 bytes
Type 20 (SUBTHREAD           ):     96 bytes
Type 21 (STACK_FRAME         ): 12955020 bytes
Type 22 (TIMER_HEAD          ):    144 bytes
Type 27 (FINALIZER_HEAD      ):    120 bytes
Type 31 (IO_PORT             ):    180 bytes
Type 34 (APPDOMAIN_HEAD      ):     72 bytes
Type 36 (APPDOMAIN_ASSEMBLY  ):   3060 bytes
GC: 1147msec 13032204 bytes used, 8844 bytes available
Type 0F (STRING              ):   1416 bytes
Type 11 (CLASS               ):  11496 bytes
Type 12 (VALUETYPE           ):   1476 bytes
Type 13 (SZARRAY             ):   4380 bytes
Type 15 (FREEBLOCK           ):   8844 bytes
Type 17 (ASSEMBLY            ):  29160 bytes
Type 18 (WEAKCLASS           ):    192 bytes
Type 19 (REFLECTION          ):    168 bytes
Type 1B (DELEGATE_HEAD       ):    792 bytes
Type 1D (OBJECT_TO_EVENT     ):    216 bytes
Type 1E (BINARY_BLOB_HEAD    ):    192 bytes
Type 1F (THREAD              ):    768 bytes
Type 20 (SUBTHREAD           ):     96 bytes
Type 21 (STACK_FRAME         ): 12978276 bytes
Type 22 (TIMER_HEAD          ):    144 bytes
Type 27 (FINALIZER_HEAD      ):    120 bytes
Type 31 (IO_PORT             ):    180 bytes
Type 34 (APPDOMAIN_HEAD      ):     72 bytes
Type 36 (APPDOMAIN_ASSEMBLY  ):   3060 bytes
Failed allocation for 17 blocks, 204 bytes

GC: 1147msec 13032264 bytes used, 8784 bytes available
Type 0F (STRING              ):   1416 bytes
Type 11 (CLASS               ):  11556 bytes
Type 12 (VALUETYPE           ):   1476 bytes
Type 13 (SZARRAY             ):   4380 bytes
Type 15 (FREEBLOCK           ):   8784 bytes
Type 17 (ASSEMBLY            ):  29160 bytes
Type 18 (WEAKCLASS           ):    192 bytes
Type 19 (REFLECTION          ):    168 bytes
Type 1B (DELEGATE_HEAD       ):    792 bytes
Type 1D (OBJECT_TO_EVENT     ):    216 bytes
Type 1E (BINARY_BLOB_HEAD    ):    192 bytes
Type 1F (THREAD              ):    768 bytes
Type 20 (SUBTHREAD           ):     96 bytes
Type 21 (STACK_FRAME         ): 12978276 bytes
Type 22 (TIMER_HEAD          ):    144 bytes
Type 27 (FINALIZER_HEAD      ):    120 bytes
Type 31 (IO_PORT             ):    180 bytes
Type 34 (APPDOMAIN_HEAD      ):     72 bytes
Type 36 (APPDOMAIN_ASSEMBLY  ):   3060 bytes
Failed allocation for 42415 blocks, 508980 bytes

GC: 1147msec 13032444 bytes used, 8604 bytes available
Type 0F (STRING              ):   1416 bytes
Type 11 (CLASS               ):  11556 bytes
Type 12 (VALUETYPE           ):   1476 bytes
Type 13 (SZARRAY             ):   4380 bytes
Type 15 (FREEBLOCK           ):   8604 bytes
Type 17 (ASSEMBLY            ):  29160 bytes
Type 18 (WEAKCLASS           ):    192 bytes
Type 19 (REFLECTION          ):    168 bytes
Type 1B (DELEGATE_HEAD       ):    792 bytes
Type 1D (OBJECT_TO_EVENT     ):    216 bytes
Type 1E (BINARY_BLOB_HEAD    ):    372 bytes
Type 1F (THREAD              ):    768 bytes
Type 20 (SUBTHREAD           ):     96 bytes
Type 21 (STACK_FRAME         ): 12978276 bytes
Type 22 (TIMER_HEAD          ):    144 bytes
Type 27 (FINALIZER_HEAD      ):    120 bytes
Type 31 (IO_PORT             ):    180 bytes
Type 34 (APPDOMAIN_HEAD      ):     72 bytes
Type 36 (APPDOMAIN_ASSEMBLY  ):   3060 bytes
Failed allocation for 39 blocks, 468 bytes

I googled around and found out that there is a problem with the GC in .NETMF 4.1 and so downloaded and installed the .NETMF 4.2 (RC) as this apparently should solve any GC memory allocation problems.

The only problem is, the FEZ Spider is running .NETMF 4.1 on its firmware and so doesn’t even attempt to deploy as it says there is a conflict between the program’s 4.2 and the Spider’s 4.1.

I was wondering if anyone has managed to get the Usb Serial module working? Either with 4.1 or 4.2?

And if not, will there be a FEZ Spider .NETMF 4.2 firmware coming anytime soon? Because I would really like to use this module.

Thanks for your time,

Poncho

Mike · November 14, 2011, 4:30pm

GHI has stated that 4.2 support will not be available until 1Q12.

According to the output you included, you are using more than 13 megabytes of RAM.

What are you doing?

Gus_Issa · November 14, 2011, 4:34pm

The gc problem is an enhancement for devices with little memory and it will not effect your spider.

Poncho · November 14, 2011, 4:45pm

Ah okay thanks for the quick replies.

I’m not really doing anything.

It even happens if all I do is:

GT.Interfaces.Serial serialLine = usbSerial.SerialLine;

But when I comment the line out (so the only other line in the default project is Debug.Print(“Program Started.”); ) it is fine again.

Any ideas?

I’ve tried using a different spider, usb cable, serial module etc. but to no avail.

Thanks,

Poncho

Gus_Issa · November 14, 2011, 4:47pm

Let us give it a try and will get back to you

Poncho · November 15, 2011, 10:09am

Okay thanks for the help Gus.

I’ll look forward to seeing what you find out.

Poncho

Poncho · November 15, 2011, 11:45am

Okay,

We managed to find the problem. There is a problem with the UsbSerial class as it always spits out the errors I quoted in the first post.

If you go a level up and create a serial connection in code like:

GT.Interfaces.Serial serial = new GT.Interfaces.Serial(GT.Socket.GetSocket(11, false, null, null), 9600, GT.Interfaces.Serial.SerialParity.None, GT.Interfaces.Serial.SerialStopBits.One, 8, GT.Interfaces.Serial.HardwareFlowControl.NotRequired, null);

it will work, so there is something wrong in the higher level UsbSerial class. I don’t know if this is a GHI problem or Microsoft problem but if anyone else has the same problem, do it the above way.

Thanks,

Poncho

User_12 · November 15, 2011, 7:59pm

Why don’t you take a look at USBSerial class source code? you might find and contribute the solution
You know .NET Gadgeteer is an opensource project
Here is the link to the source coude
[url]http://gadgeteer.codeplex.com/SourceControl/changeset/view/13828#138303[/url]

Poncho · November 24, 2011, 11:03am

I’ll have a go, time to get the debugger out!

Thanks for the link.

Bec_a_Fuel · November 25, 2011, 3:45am

It seems the class needs more than one fix.

The first one is simple. In the following code, you should replace SerialLine with _SerialLine in the first “if” test. This one leads to a never-ending loop because the test is using the public property, which is testing for a private var and call Configure() if this var is not set. Configure() then call the property again and so on… :wall:

public void Configure(int baudRate, GTI.Serial.SerialParity parity, GTI.Serial.SerialStopBits stopBits, int dataBits)
        {
            if (_SerialLine != null)  // NOT SerialLine without underscore
            {
                throw new Exception("UsbSerial.Configure can only be called once");
            }
            // TODO: check if HW flow control should be used
            SerialLine = new GTI.Serial(socket, baudRate, parity, stopBits, dataBits, GTI.Serial.HardwareFlowControl.UseIfAvailable, this);
        }

Now, this is not enough since it throws an exception after that with conflicting pins :’(

[quote]Using mainboard GHIElectronics-FEZHydra version 1.0
#### Exception Gadgeteer.Socket+PinConflictException - 0x00000000 (1) ####
#### Message:
Unable to configure the MyUsbSerial module using socket 6 (pin 4). There is a conflict with the MyUsbSerial module using socket 6 (pin 4). Please try using a different combination of sockets.
#### Gadgeteer.Socket::ReservePin [IP: 003a] ####
#### Gadgeteer.Interfaces.Serial::.ctor [IP: 00ec] ####
#### GadgeteerApp2.MyUsbSerial::Configure [IP: 0023] ####
#### GadgeteerApp2.Program::ProgramStarted [IP: 0018] ####
#### GadgeteerApp2.Program::Main [IP: 0015] ####
Une exception de première chance de type ‘Gadgeteer.Socket.PinConflictException’ s’est produite dans Gadgeteer.dll
Une exception non gérée du type ‘Gadgeteer.Socket.PinConflictException’ s’est produite dans Gadgeteer.dll

Informations supplémentaires : @ � `[/quote]

Ascii chars after the text “Informations supplémentaires” is exactly what I get, it’s not some conversion problem.

Pin 4 is assigned to the _sleepbar variable as interrupt port. I still have to understand how all this is working before trying to fix it, though. A simple removal of this variable does not solve the problem.

Bec_a_Fuel · November 25, 2011, 5:00am

Here are some other informations :

I’ve resolved the conflicting pin problem by assigning the _SleepBar to Pin.Eight. But I don’t know yet what it implies elsewhere.

But there’s worse : everything different than “COM1” does throw an exception in the SerialPort constructor :o (in Gadgeteer/Interfaces/Serial.cs)
Unfortunately, none of the UART sockets shows such com port
[ulist]S7->com2
S6->com4
S5->com2
S4->com3 [/ulist]

You will also notice that com2 is present twice, which doesn’t seem good ??? Well, maybe not good but consistent with info in the schematics as pin naming is (almost) the same for serial pins on sockets 5 & 7. I think the different naming on socket 5 is a typo ?

If I force “COM1” in the serial port constructor, then everything seems to run but I can’t be sure as I get read/write timeouts, which is expected here, of course, since I don’t have any COM1. But there are no exceptions or errors whatsoever.

I hope it will be useful to whoever is concerned here.

[italic]Edit:[/italic] : this test has been done on a Hydra board. I don’t have a Spider so I can’t predict if it behaves identical on both boards. Maybe the first fix (_SerialLine instead of SerialLine) is enough. This has to be checked.

Gus_Issa · November 25, 2011, 8:17am

Will look into it.

Bec_a_Fuel · November 28, 2011, 3:10pm

After looking at the schematics, it appears that CBUS4 pin on the FT232 chip is not connected to anything.

So, _SleepBar has no use (yet ?) and could be re-mapped to a free pin (8 or 9) without trouble I think. This would free pin4, which is already assigned to RXD.

This would solve the conflicting pin problem. What do you think ? :think:

Steven_ghielectroncs · November 28, 2011, 3:38pm

Right now, you wont need the lines:

_RIBar = new GTI.DigitalOutput(socket, Socket.Pin.Three, true, this);
            _SleepBar = new GTI.InterruptInput(socket, Socket.Pin.Four, GTI.GlitchFilterMode.Off, GTI.ResistorMode.Disabled, GTI.InterruptMode.RisingAndFallingEdge, this);
            _SleepBar.Interrupt += new GTI.InterruptInput.InterruptEventHandler(_SleepBar_Interrupt);

Also, the driver that is online is unusable, and we are working on updating the drivers right now.

Bec_a_Fuel · November 28, 2011, 3:47pm

Indeed. And I also have to “remove” all the methods that refer to those variables.

But I think this one is no big deal, much like the one solved in reply #9. Please see reply #10 for other headaches :whistle:

Steven_ghielectroncs · November 29, 2011, 9:42am

So I think we’ve got this figured out. At the moment, the only COM port that is enabled is COM1, which would be on socket 5. As far as two of the sockets sharing COM2, that is a typo.

S7->com2
S6->com4
S5->com1
S4->com3
Also, the line


 _SerialLine = new GTI.Serial(socket, baudRate, parity, stopBits, dataBits, GTI.Serial.HardwareFlowControl.UseIfAvailable, this);

should be


_SerialLine = new GTI.Serial(socket, baudRate, parity, stopBits, dataBits, GTI.Serial.HardwareFlowControl.NotRequired, this);

All of the above is only related to Hydra. Removing the 3 mentioned lines of code and swapping SerialLine with _SerialLine should make it work for Spider.