Console app freezes

[Guest]

Hi,

I’ve written a C# console app that does a lot of things simultaneously. The
device being used is an FB6500 (http://www.fabiatech.com/products/fb6500.htm)
running Windows CE 5.0. These are all the things the app does:

1. Uses four threads to scan four COM ports – each port processes real time
data composed of packets. These packets are on average 25 bytes long and
throughput is around 15 packets/sec. So all ports combined process 60
packets/sec.

2. Opens two network sockets – 1 for sending data and another for receiving.
The receiving socket listens for incoming commands from a connected client.

3. Uses 3 timers – one which runs every 10 seconds sends 1500 bytes of data
through a socket to a connected client, another which runs every minute
checks the status of certain variables, and the third runs every hour and
uses RDA (remote data access) to synchronize a remote SQL Server 2000
database.

4. Keeps a log of things that may happen by keeping a file open and writing
to it when necessary.

I also need to run a client on a desktop PC which connects to the listening
socket of the app on the device. This client simply receives the 1500 bytes
of data every ten seconds and updates a form. When running the app on the
device, it works fine functionally but I have noticed that a lot of times the
console app freezes after a while (the mouse is still movable but I can’t
press anything, the system time at the bottom right corner also freezes). I
ran it overnight last night and this morning when I checked it, it was still
running. I then ran it again and after 20 mins or so it freezes. The amount
of time it takes until it freezes is unpredictable. The funny thing is when
running it under VS.NET debug mode, after the app freezes, the serial
processing is still taking place, it’s the networking stuff that’s stopped
(i.e. the client no longer receives the 1500 bytes every ten secs). Would the
number of threads running cause this freezing to take place? I honestly don’t
know where to begin to fix this problem. My app NEEDS to run for long periods
of time (i.e. over 12 hours). Can anyone shed any light on what might be
causing this or where I should start looking? Thanks in advance.

Kind Regards,

Michael--J

 

[Ilya Tumanov [MS]]

You probably have a race condition somewhere; this is the common reason for
multithreaded applications to hang.

Make sure all shared (between threads) objects are properly locked/unlocked.



Best regards,



Ilya



This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Guest]

Thanks for your quick reply. I see what you are getting at. But how would a
race condition cause a hang? I thought it usually just corrupts the proper
value of an object or variable.

I'm getting quite worried because i have been working on this app for quite
some time now and to find out it can't last for long periods of time is
really disappointing. I just want to make sure whether things like this are
fixable or if it's inherent with running multithreaded apps on
resource-contrained devices. It's just very wierd that sometimes it runs for
hours (it ran for 10 hours once) and at other times it freezes after 20, or
30 mins or so. I'll have a look and see if i can find any race conditions.
Thanks in advance.

Michael--J.

 

[Ilya Tumanov [MS]]

If something's corrupted, anything could happen.
May be, you have a loop you could never leave because another thread
messing with loop counter.
Or, may be, you have a classical deadlock. Whatever the reason, it is
fixable.

Just carefully identify all shared objects and add locking if these objects
are not thread safe.

If you're using some sort of custom semaphores (not the lock statement),
don't forget to unlock objects even if you have an exception.
You might use finally blocks to do so.

Best regards,

Ilya

This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------

Thread-Topic: Console app freezes
thread-index: AcTjYMfjNS4Xr4DlR9GS/Qlk1bulQw==
X-WBNR-Posting-Host: 211.26.115.247
From: "=?Utf-8?B?TWljaGFlbC0tSg==?=" <[email protected]>
References: <[email protected]>

 

[Guest]

Hi,

I did more tests and have encountered a few strange behaviours. The test
only involved port1 and port3. Each port processed serial input composed of
40 packets/sec where each packet averaged around 30 bytes in size. In the
background, i still have the same 3 timers working as well as the IP stuff
(refer to my first post regarding what my app does).

Ok, when i deploy the app to my device in debug mode, it runs fine until
some arbitrary point in time where the console just freezes (Console's cursor
stops flashing and system time stops). However, after waiting a while, I
noticed that the cursor actually blinked to it’s opposite colour and the time
updated itself to the current time and then it “freezes†again. I don’t think
the app is actually “frozenâ€, it’s still running (in the background somehow)
but the IP networking stuff isn’t active. Then i decided to remove port1's
serial input and after some time, the app began to work properly again (i.e.
Console's cursor was flashing and the system time was working). I reconnect
port1's input, the app "freezes" again after a while. I remove port1's input,
and it works again, and so on.

Does having 4 separate threads, each processing serial input, cause problems
in resource-contrained devices or is this still a race condition issue? Any
ideas as to why the behaviour i mentioned above happens? Thanks in advance.

Michael--J.

If something's corrupted, anything could happen.
May be, you have a loop you could never leave because another thread
messing with loop counter.
Or, may be, you have a classical deadlock. Whatever the reason, it is
fixable.

Just carefully identify all shared objects and add locking if these objects
are not thread safe.

If you're using some sort of custom semaphores (not the lock statement),
don't forget to unlock objects even if you have an exception.
You might use finally blocks to do so.

Best regards,

Ilya

This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------

Thread-Topic: Console app freezes
thread-index: AcTjYMfjNS4Xr4DlR9GS/Qlk1bulQw==
X-WBNR-Posting-Host: 211.26.115.247
From: "=?Utf-8?B?TWljaGFlbC0tSg==?=" <[email protected]>
References: <[email protected]>

Subject: Re: Console app freezes
Date: Thu, 16 Dec 2004 03:17:08 -0800
Lines: 100
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: text/plain;
charset="Utf-8"
Content-Transfer-Encoding: 7bit
X-Newsreader: Microsoft CDO for Windows 2000
Content-Class: urn:content-classes:message
Importance: normal
Priority: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
Newsgroups: microsoft.public.dotnet.framework.compactframework
NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.1.29
Path: cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl
Xref: cpmsftngxa10.phx.gbl microsoft.public.dotnet.framework.compactframework:67045
X-Tomcat-NG: microsoft.public.dotnet.framework.compactframework

Thanks for your quick reply. I see what you are getting at. But how would a
race condition cause a hang? I thought it usually just corrupts the proper
value of an object or variable.

I'm getting quite worried because i have been working on this app for quite
some time now and to find out it can't last for long periods of time is
really disappointing. I just want to make sure whether things like this are
fixable or if it's inherent with running multithreaded apps on
resource-contrained devices. It's just very wierd that sometimes it runs for
hours (it ran for 10 hours once) and at other times it freezes after 20, or
30 mins or so. I'll have a look and see if i can find any race conditions.
Thanks in advance.

Michael--J.

 

[Ilya Tumanov [MS]]

This behavior seem to be a result if excessive CPU load.
Do you have some tight loops anywhere? Say, waiting for something?
Do you know what your app will do in case more data is coming from serial
port(s) than can be processed?
Could it wait for available buffer in a loop without sleep() in it?
That would cause the "serial" thread to use 100% CPU, which would slow down
all other thread, which would slow down data processing, which would cause
"serial" thread to wait... and so on. As you remove incoming data, your app
would eventually process data and unlock itself.

Best regards,

Ilya

This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------

Thread-Topic: Console app freezes
thread-index: AcTmVRfikLPVHZaeRoiMCjHGM79gMA==
X-WBNR-Posting-Host: 202.6.138.45
From: "=?Utf-8?B?TWljaGFlbC0tSg==?=" <[email protected]>
References: <[email protected]>

<[email protected]>

Subject: Re: Console app freezes
Date: Sun, 19 Dec 2004 21:31:02 -0800
Lines: 204
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: text/plain;
charset="Utf-8"
Content-Transfer-Encoding: 8bit
X-Newsreader: Microsoft CDO for Windows 2000
Content-Class: urn:content-classes:message
Importance: normal
Priority: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
Newsgroups: microsoft.public.dotnet.framework.compactframework
NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.1.29
Path: cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl
Xref: cpmsftngxa10.phx.gbl microsoft.public.dotnet.framework.compactframework:67211
X-Tomcat-NG: microsoft.public.dotnet.framework.compactframework

Hi,

I did more tests and have encountered a few strange behaviours. The test
only involved port1 and port3. Each port processed serial input composed of
40 packets/sec where each packet averaged around 30 bytes in size. In the
background, i still have the same 3 timers working as well as the IP stuff
(refer to my first post regarding what my app does).

Ok, when i deploy the app to my device in debug mode, it runs fine until
some arbitrary point in time where the console just freezes (Console's cursor
stops flashing and system time stops). However, after waiting a while, I
noticed that the cursor actually blinked to it’s opposite colour and the time
updated itself to the current time and then it “freezes†again. I don’t think
the app is actually “frozenâ€, it’s still running (in the background somehow)
but the IP networking stuff isn’t active. Then i decided to remove port1's
serial input and after some time, the app began to work properly again (i.e.
Console's cursor was flashing and the system time was working). I reconnect
port1's input, the app "freezes" again after a while. I remove port1's input,
and it works again, and so on.

Does having 4 separate threads, each processing serial input, cause problems
in resource-contrained devices or is this still a race condition issue? Any
ideas as to why the behaviour i mentioned above happens? Thanks in advance.

Michael--J.

If something's corrupted, anything could happen.
May be, you have a loop you could never leave because another thread
messing with loop counter.
Or, may be, you have a classical deadlock. Whatever the reason, it is
fixable.

Just carefully identify all shared objects and add locking if these objects
are not thread safe.

If you're using some sort of custom semaphores (not the lock statement),
don't forget to unlock objects even if you have an exception.
You might use finally blocks to do so.

Best regards,

Ilya

This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------

Thread-Topic: Console app freezes
thread-index: AcTjYMfjNS4Xr4DlR9GS/Qlk1bulQw==
X-WBNR-Posting-Host: 211.26.115.247
From: "=?Utf-8?B?TWljaGFlbC0tSg==?="

References: <[email protected]>

Subject: Re: Console app freezes
Date: Thu, 16 Dec 2004 03:17:08 -0800
Lines: 100
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: text/plain;
charset="Utf-8"
Content-Transfer-Encoding: 7bit
X-Newsreader: Microsoft CDO for Windows 2000
Content-Class: urn:content-classes:message
Importance: normal
Priority: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
Newsgroups: microsoft.public.dotnet.framework.compactframework
NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.1.29
Path: cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl
Xref: cpmsftngxa10.phx.gbl microsoft.public.dotnet.framework.compactframework:67045
X-Tomcat-NG: microsoft.public.dotnet.framework.compactframework

Thanks for your quick reply. I see what you are getting at. But how

would
a

race condition cause a hang? I thought it usually just corrupts the proper
value of an object or variable.

I'm getting quite worried because i have been working on this app for quite
some time now and to find out it can't last for long periods of time is
really disappointing. I just want to make sure whether things like

this
are

fixable or if it's inherent with running multithreaded apps on
resource-contrained devices. It's just very wierd that sometimes it

runs
for

hours (it ran for 10 hours once) and at other times it freezes after

20,
or

30 mins or so. I'll have a look and see if i can find any race conditions.
Thanks in advance.

Michael--J.

:

You probably have a race condition somewhere; this is the common

reason
for

multithreaded applications to hang.

Make sure all shared (between threads) objects are properly locked/unlocked.



Best regards,



Ilya



This posting is provided "AS IS" with no warranties, and confers no rights.


Hi,

I've written a C# console app that does a lot of things simultaneously.
The
device being used is an FB6500
(http://www.fabiatech.com/products/fb6500.htm)
running Windows CE 5.0. These are all the things the app does:

1. Uses four threads to scan four COM ports - each port processes real
time
data composed of packets. These packets are on average 25 bytes

long
and

throughput is around 15 packets/sec. So all ports combined process 60
packets/sec.

2. Opens two network sockets - 1 for sending data and another for
receiving.
The receiving socket listens for incoming commands from a connected
client.

3. Uses 3 timers - one which runs every 10 seconds sends 1500

bytes
of

data
through a socket to a connected client, another which runs every minute
checks the status of certain variables, and the third runs every

hour
and

uses RDA (remote data access) to synchronize a remote SQL Server 2000
database.

4. Keeps a log of things that may happen by keeping a file open and
writing
to it when necessary.

I also need to run a client on a desktop PC which connects to the
listening
socket of the app on the device. This client simply receives the 1500
bytes
of data every ten seconds and updates a form. When running the

app on
the

device, it works fine functionally but I have noticed that a lot

of
times

the
console app freezes after a while (the mouse is still movable but

I
can't

press anything, the system time at the bottom right corner also freezes).
I
ran it overnight last night and this morning when I checked it,

it
was

still
running. I then ran it again and after 20 mins or so it freezes. The
amount
of time it takes until it freezes is unpredictable. The funny

thing
is

when
running it under VS.NET debug mode, after the app freezes, the serial
processing is still taking place, it's the networking stuff

that's
stopped

(i.e. the client no longer receives the 1500 bytes every ten

secs).
Would

the
number of threads running cause this freezing to take place? I honestly
don't
know where to begin to fix this problem. My app NEEDS to run for long
periods
of time (i.e. over 12 hours). Can anyone shed any light on what

might
be

causing this or where I should start looking? Thanks in advance.

Kind Regards,

Michael--J

 

[Guest]

I've found in my .NET TCP/IP projects (on Pocket PC) that the sockets
can starve very easily if there is a lack of system idle time. I
actually had to put in Application.DoEvents into my communication code.
I can only assume the TCP/IP classes use hidden windows for internal
messaging and the message pump was getting backlogged. Use great
caution with the DoEvents, you don't want to over do it.

HTH,
Tom C.

 

[Guest]

My app uses OpenNETCF.org’s serial comms code with a few modifications in
their Port.cs class. This class simply sets up a thread called
‘CommEventThread’ that continually loops the associated com port for data.
However, I had to modify this to reflect the modifications I made to the
lower level serial drivers. The serial drivers were changed such that it
suited the data it was processing. The data was basically composed of packets
separated by parity errors. I couldn’t use a parity error event to
distinguish between packets because the app couldn’t keep up with the number
of parity error events being raised. Instead, I modified the serial driver
such that it places an escape ‘f0’ character in the receive stream whenever
it detected a parity error and my app simply needed to locate this ‘f0’
character. To distinguish between an escape ‘f0’ character between an actual
data ‘f0’, I replaced the data one with a 6-byte signature which my higher
level app also searches for. So in pseudo code, this is how the
CommEventThread in Port.cs looks like:

private void CommEventThread()
{
while(hPort != invalidHandle)
{

// Wait for a comm event to take place;
WaitForCommEvent();

if(error event)
{
// Handle error;
}

if(data received)
{
do
{
ReadFile() to rxFIFO buffer;
}while(bytesread > 0)
}

while(rxFIFO.Count > 0)
{
byte u = rxFIFO.Dequeue();

if(u == any byte)
{
// Add ‘u’ to progressBuffer ArrayList
progressBuffer.Add(u);
}

if(u == ‘f0’)
{
// Raise ParityError() event and clear progressBuffer;
ParityError();
progressBuffer = new ArrayList();
}

if(u is part of 6-byte signature)
{
// Take note of it;
}

if(u is last byte of 6-byte signature)
{
// Insert ‘f0’ in the data;
progressBuffer.Add(u);
}
}
}
}

I also added the method ReadProgressBuffer() in Port.cs which gets the
current progressBuffer contents when a parity error event is raised. This
will be called by my main app.

public byte[] ReadProgressBuffer(){
return (byte[])progressBuffer.ToArray(typeof(byte));
}

In my main code, I instantiate 4 port objects which means that I introduce 4
CommEventThreads executing the above code in non-stop looping. My main also
handles the ParityError events raised by each port by creating 4 indentical
event handlers that process the data by firstly calling
portX.ReadProgressBuffer(). Below is the pseudo code:

private void portX_ParityError()
{
byte[] packet = portX.ReadProgressBuffer();

// Process the byte array here;
// This predominantly involves packet validation -
// CRC checks, and updating a set of global data;
}

When this handler returns, the CommEventThread continues by clearing the
progressBuffer and repeating the whole process.

In addition to this, I have 3 timers, TCP/IP stuff, and log keeping (as
described in my first post). Would it definitely be a CPU overload issue? If
you need more information regarding my app or any of its code, please feel
free to ask. Thanks again.

This behavior seem to be a result if excessive CPU load.
Do you have some tight loops anywhere? Say, waiting for something?
Do you know what your app will do in case more data is coming from serial
port(s) than can be processed?
Could it wait for available buffer in a loop without sleep() in it?
That would cause the "serial" thread to use 100% CPU, which would slow down
all other thread, which would slow down data processing, which would cause
"serial" thread to wait... and so on. As you remove incoming data, your app
would eventually process data and unlock itself.

Best regards,

Ilya

 

[Guest]

Would it matter if my app was only a console app. Isn't the Application class
found within the System.Windows.Forms namespace? Thanks.

 

[Ilya Tumanov [MS]]

What's in WaitForCommEvent()? It's not a while loop which checks for some
variable set from event, is it?

I would also suggest using circular buffer instead of creating new array
lists and arrays for every packet.
You'll need to firure out what to do in case buffer overflows (terminate,
log event, ignore extra data, etc.).

Best regards,

Ilya

This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------

Thread-Topic: Console app freezes
thread-index: AcTm7jZvbF/weKNQT22YrExp4stGvg==
X-WBNR-Posting-Host: 202.6.138.45
From: "=?Utf-8?B?TWljaGFlbC0tSg==?=" <[email protected]>
References: <[email protected]>

<[email protected]>
<[email protected]>
<[email protected]>

Subject: Re: Console app freezes
Date: Mon, 20 Dec 2004 15:47:06 -0800
Lines: 116
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: text/plain;
charset="Utf-8"
Content-Transfer-Encoding: 8bit
X-Newsreader: Microsoft CDO for Windows 2000
Content-Class: urn:content-classes:message
Importance: normal
Priority: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
Newsgroups: microsoft.public.dotnet.framework.compactframework
NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.1.29
Path: cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl
Xref: cpmsftngxa10.phx.gbl microsoft.public.dotnet.framework.compactframework:67289
X-Tomcat-NG: microsoft.public.dotnet.framework.compactframework

My app uses OpenNETCF.org’s serial comms code with a few modifications in
their Port.cs class. This class simply sets up a thread called
‘CommEventThread’ that continually loops the associated com port for data.
However, I had to modify this to reflect the modifications I made to the
lower level serial drivers. The serial drivers were changed such that it
suited the data it was processing. The data was basically composed of packets
separated by parity errors. I couldn’t use a parity error event to
distinguish between packets because the app couldn’t keep up with the number
of parity error events being raised. Instead, I modified the serial driver
such that it places an escape ‘f0’ character in the receive stream whenever
it detected a parity error and my app simply needed to locate this ‘ f0’
character. To distinguish between an escape ‘f0’ character between an actual
data ‘f0’, I replaced the data one with a 6-byte signature which my higher
level app also searches for. So in pseudo code, this is how the
CommEventThread in Port.cs looks like:

private void CommEventThread()
{
while(hPort != invalidHandle)
{

// Wait for a comm event to take place;
WaitForCommEvent();

if(error event)
{
// Handle error;
}

if(data received)
{
do
{
ReadFile() to rxFIFO buffer;
}while(bytesread > 0)
}

while(rxFIFO.Count > 0)
{
byte u = rxFIFO.Dequeue();

if(u == any byte)
{
// Add ‘u’ to progressBuffer ArrayList
progressBuffer.Add(u);
}

if(u == ‘f0’)
{
// Raise ParityError() event and clear progressBuffer;
ParityError();
progressBuffer = new ArrayList();
}

if(u is part of 6-byte signature)
{
// Take note of it;
}

if(u is last byte of 6-byte signature)
{
// Insert ‘f0’ in the data;
progressBuffer.Add(u);
}
}
}
}

I also added the method ReadProgressBuffer() in Port.cs which gets the
current progressBuffer contents when a parity error event is raised. This
will be called by my main app.

public byte[] ReadProgressBuffer(){
return (byte[])progressBuffer.ToArray(typeof(byte));
}

In my main code, I instantiate 4 port objects which means that I introduce 4
CommEventThreads executing the above code in non-stop looping. My main also
handles the ParityError events raised by each port by creating 4 indentical
event handlers that process the data by firstly calling
portX.ReadProgressBuffer(). Below is the pseudo code:

private void portX_ParityError()
{
byte[] packet = portX.ReadProgressBuffer();

// Process the byte array here;
// This predominantly involves packet validation -
// CRC checks, and updating a set of global data;
}

When this handler returns, the CommEventThread continues by clearing the
progressBuffer and repeating the whole process.

In addition to this, I have 3 timers, TCP/IP stuff, and log keeping (as
described in my first post). Would it definitely be a CPU overload issue? If
you need more information regarding my app or any of its code, please feel
free to ask. Thanks again.

This behavior seem to be a result if excessive CPU load.
Do you have some tight loops anywhere? Say, waiting for something?
Do you know what your app will do in case more data is coming from serial
port(s) than can be processed?
Could it wait for available buffer in a loop without sleep() in it?
That would cause the "serial" thread to use 100% CPU, which would slow down
all other thread, which would slow down data processing, which would cause
"serial" thread to wait... and so on. As you remove incoming data, your app
would eventually process data and unlock itself.

Best regards,

Ilya

 

[Guest]

WaitCommEvent() is actually a P/invoke method which calls the Win API's
(coredll.dll) WaitCommEvent() method. Quoting the MSDN: "This function waits
for an event to occur for a specified communications device. The set of
events that are monitored by WaitCommEvent is contained in the event mask
associated with the device handle."

Would calling WaitCommEvent be a problem?

I will see if i can use a circular buffer. Thanks.

What's in WaitForCommEvent()? It's not a while loop which checks for some
variable set from event, is it?

I would also suggest using circular buffer instead of creating new array
lists and arrays for every packet.
You'll need to firure out what to do in case buffer overflows (terminate,
log event, ignore extra data, etc.).

Best regards,

Ilya

This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------

Thread-Topic: Console app freezes
thread-index: AcTm7jZvbF/weKNQT22YrExp4stGvg==
X-WBNR-Posting-Host: 202.6.138.45
From: "=?Utf-8?B?TWljaGFlbC0tSg==?=" <[email protected]>
References: <[email protected]>

<[email protected]>
<[email protected]>
<[email protected]>

Subject: Re: Console app freezes
Date: Mon, 20 Dec 2004 15:47:06 -0800
Lines: 116
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: text/plain;
charset="Utf-8"
Content-Transfer-Encoding: 8bit
X-Newsreader: Microsoft CDO for Windows 2000
Content-Class: urn:content-classes:message
Importance: normal
Priority: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
Newsgroups: microsoft.public.dotnet.framework.compactframework
NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.1.29
Path: cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl
Xref: cpmsftngxa10.phx.gbl microsoft.public.dotnet.framework.compactframework:67289
X-Tomcat-NG: microsoft.public.dotnet.framework.compactframework

My app uses OpenNETCF.org’s serial comms code with a few modifications in
their Port.cs class. This class simply sets up a thread called
‘CommEventThread’ that continually loops the associated com port for data.
However, I had to modify this to reflect the modifications I made to the
lower level serial drivers. The serial drivers were changed such that it
suited the data it was processing. The data was basically composed of packets
separated by parity errors. I couldn’t use a parity error event to
distinguish between packets because the app couldn’t keep up with the number
of parity error events being raised. Instead, I modified the serial driver
such that it places an escape ‘f0’ character in the receive stream whenever
it detected a parity error and my app simply needed to locate this ‘ f0’
character. To distinguish between an escape ‘f0’ character between an actual
data ‘f0’, I replaced the data one with a 6-byte signature which my higher
level app also searches for. So in pseudo code, this is how the
CommEventThread in Port.cs looks like:

private void CommEventThread()
{
while(hPort != invalidHandle)
{

// Wait for a comm event to take place;
WaitForCommEvent();

if(error event)
{
// Handle error;
}

if(data received)
{
do
{
ReadFile() to rxFIFO buffer;
}while(bytesread > 0)
}

while(rxFIFO.Count > 0)
{
byte u = rxFIFO.Dequeue();

if(u == any byte)
{
// Add ‘u’ to progressBuffer ArrayList
progressBuffer.Add(u);
}

if(u == ‘f0’)
{
// Raise ParityError() event and clear progressBuffer;
ParityError();
progressBuffer = new ArrayList();
}

if(u is part of 6-byte signature)
{
// Take note of it;
}

if(u is last byte of 6-byte signature)
{
// Insert ‘f0’ in the data;
progressBuffer.Add(u);
}
}
}
}

I also added the method ReadProgressBuffer() in Port.cs which gets the
current progressBuffer contents when a parity error event is raised. This
will be called by my main app.

public byte[] ReadProgressBuffer(){
return (byte[])progressBuffer.ToArray(typeof(byte));
}

In my main code, I instantiate 4 port objects which means that I introduce 4
CommEventThreads executing the above code in non-stop looping. My main also
handles the ParityError events raised by each port by creating 4 indentical
event handlers that process the data by firstly calling
portX.ReadProgressBuffer(). Below is the pseudo code:

private void portX_ParityError()
{
byte[] packet = portX.ReadProgressBuffer();

// Process the byte array here;
// This predominantly involves packet validation -
// CRC checks, and updating a set of global data;
}

When this handler returns, the CommEventThread continues by clearing the
progressBuffer and repeating the whole process.

In addition to this, I have 3 timers, TCP/IP stuff, and log keeping (as
described in my first post). Would it definitely be a CPU overload issue? If
you need more information regarding my app or any of its code, please feel
free to ask. Thanks again.

This behavior seem to be a result if excessive CPU load.
Do you have some tight loops anywhere? Say, waiting for something?
Do you know what your app will do in case more data is coming from serial
port(s) than can be processed?
Could it wait for available buffer in a loop without sleep() in it?
That would cause the "serial" thread to use 100% CPU, which would slow down
all other thread, which would slow down data processing, which would cause
"serial" thread to wait... and so on. As you remove incoming data, your app
would eventually process data and unlock itself.

Best regards,

Ilya

 

[Ilya Tumanov [MS]]

No, it should not cause problems as it would release ticks to OS while
waiting.

If you leave only, say, two serial ports, is it working? Is it working if
you discard of serial data without processing it?

About timers: are you using one in Windows.Forms or in System.Threading?

Best regards,

Ilya


This posting is provided "AS IS" with no warranties, and confers no rights.


--------------------

Thread-Topic: Console app freezes
thread-index: AcTnAKQ4g7fe4r2XTIeutiQV26gjCw==
X-WBNR-Posting-Host: 202.6.138.45
From: "=?Utf-8?B?TWljaGFlbC0tSg==?=" <[email protected]>
References: <[email protected]>

<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>

Subject: Re: Console app freezes
Date: Mon, 20 Dec 2004 17:59:01 -0800
Lines: 193
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: text/plain;
charset="Utf-8"
Content-Transfer-Encoding: 8bit
X-Newsreader: Microsoft CDO for Windows 2000
Content-Class: urn:content-classes:message
Importance: normal
Priority: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
Newsgroups: microsoft.public.dotnet.framework.compactframework
NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.1.29
Path: cpmsftngxa10.phx.gbl!TK2MSFTFEED02.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGXA0
3.phx.gbl
Xref: cpmsftngxa10.phx.gbl microsoft.public.dotnet.framework.compactframework:67300
X-Tomcat-NG: microsoft.public.dotnet.framework.compactframework

WaitCommEvent() is actually a P/invoke method which calls the Win API's
(coredll.dll) WaitCommEvent() method. Quoting the MSDN: "This function waits
for an event to occur for a specified communications device. The set of
events that are monitored by WaitCommEvent is contained in the event mask
associated with the device handle."

Would calling WaitCommEvent be a problem?

I will see if i can use a circular buffer. Thanks.

What's in WaitForCommEvent()? It's not a while loop which checks for some
variable set from event, is it?

I would also suggest using circular buffer instead of creating new array
lists and arrays for every packet.
You'll need to firure out what to do in case buffer overflows (terminate,
log event, ignore extra data, etc.).

Best regards,

Ilya

This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------

Thread-Topic: Console app freezes
thread-index: AcTm7jZvbF/weKNQT22YrExp4stGvg==
X-WBNR-Posting-Host: 202.6.138.45
From: "=?Utf-8?B?TWljaGFlbC0tSg==?="

References: <[email protected]>

<[email protected]>
<[email protected]>
<[email protected]>

Subject: Re: Console app freezes
Date: Mon, 20 Dec 2004 15:47:06 -0800
Lines: 116
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: text/plain;
charset="Utf-8"
Content-Transfer-Encoding: 8bit
X-Newsreader: Microsoft CDO for Windows 2000
Content-Class: urn:content-classes:message
Importance: normal
Priority: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
Newsgroups: microsoft.public.dotnet.framework.compactframework
NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.1.29
Path: cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl
Xref: cpmsftngxa10.phx.gbl microsoft.public.dotnet.framework.compactframework:67289
X-Tomcat-NG: microsoft.public.dotnet.framework.compactframework

My app uses OpenNETCF.org’s serial comms code with a few

modifications
in

their Port.cs class. This class simply sets up a thread called
‘CommEventThread’ that continually loops the associated

com port for
data.

However, I had to modify this to reflect the modifications I made to the
lower level serial drivers. The serial drivers were changed such that it
suited the data it was processing. The data was basically composed of packets
separated by parity errors. I couldn’t use a parity error event to
distinguish between packets because the app couldn’t keep up

with the
number

of parity error events being raised. Instead, I modified the serial driver
such that it places an escape ‘f0’ character in the

receive stream
whenever

it detected a parity error and my app simply needed to locate this Ã

¢â‚¬Ëœ
f0’

character. To distinguish between an escape ‘f0’

character between an
actual

data ‘f0’, I replaced the data one with a 6-byte

signature which my
higher

level app also searches for. So in pseudo code, this is how the
CommEventThread in Port.cs looks like:

private void CommEventThread()
{
while(hPort != invalidHandle)
{

// Wait for a comm event to take place;
WaitForCommEvent();

if(error event)
{
// Handle error;
}

if(data received)
{
do
{
ReadFile() to rxFIFO buffer;
}while(bytesread > 0)
}

while(rxFIFO.Count > 0)
{
byte u = rxFIFO.Dequeue();

if(u == any byte)
{
// Add ‘u’ to progressBuffer ArrayList
progressBuffer.Add(u);
}

if(u == ‘f0’)
{
// Raise ParityError() event and clear progressBuffer;
ParityError();
progressBuffer = new ArrayList();
}

if(u is part of 6-byte signature)
{
// Take note of it;
}

if(u is last byte of 6-byte signature)
{
// Insert ‘f0’ in the data;
progressBuffer.Add(u);
}
}
}
}

I also added the method ReadProgressBuffer() in Port.cs which gets the
current progressBuffer contents when a parity error event is raised. This
will be called by my main app.

public byte[] ReadProgressBuffer(){
return (byte[])progressBuffer.ToArray(typeof(byte));
}

In my main code, I instantiate 4 port objects which means that I introduce 4
CommEventThreads executing the above code in non-stop looping. My

main
also

handles the ParityError events raised by each port by creating 4 indentical
event handlers that process the data by firstly calling
portX.ReadProgressBuffer(). Below is the pseudo code:

private void portX_ParityError()
{
byte[] packet = portX.ReadProgressBuffer();

// Process the byte array here;
// This predominantly involves packet validation -
// CRC checks, and updating a set of global data;
}

When this handler returns, the CommEventThread continues by clearing the
progressBuffer and repeating the whole process.

In addition to this, I have 3 timers, TCP/IP stuff, and log keeping (as
described in my first post). Would it definitely be a CPU overload

issue?
If

you need more information regarding my app or any of its code, please feel
free to ask. Thanks again.


:

This behavior seem to be a result if excessive CPU load.
Do you have some tight loops anywhere? Say, waiting for something?
Do you know what your app will do in case more data is coming from serial
port(s) than can be processed?
Could it wait for available buffer in a loop without sleep() in it?
That would cause the "serial" thread to use 100% CPU, which would

slow
down

all other thread, which would slow down data processing, which

would
cause

"serial" thread to wait... and so on. As you remove incoming data,

your
app

would eventually process data and unlock itself.

Best regards,

Ilya

 

[Guest]

At the moment, i open all 4 comports but i'm only giving serial input to 2
ports (1 & 3). When i had 20 packets/sec going into each port1 and port3, the
app worked fine (40 packets/sec total). When i increased that to 30
packets/sec each (60 packets/sec total) the app would "freeze" after a while.
Increasing it to 40 packets/sec each (80 packets/sec total) also made it
"freeze".

I then decided to test the app with only one port processing serial input. I
used port1 and inputted 80 packets/sec. It worked fine. There's some kind of
serious threading issue happening and i can't seem to pinpoint it.

Also, i am using System.Threading timers. Thanks.

No, it should not cause problems as it would release ticks to OS while
waiting.

If you leave only, say, two serial ports, is it working? Is it working if
you discard of serial data without processing it?

About timers: are you using one in Windows.Forms or in System.Threading?

Best regards,

Ilya


This posting is provided "AS IS" with no warranties, and confers no rights.


--------------------

Thread-Topic: Console app freezes
thread-index: AcTnAKQ4g7fe4r2XTIeutiQV26gjCw==
X-WBNR-Posting-Host: 202.6.138.45
From: "=?Utf-8?B?TWljaGFlbC0tSg==?=" <[email protected]>
References: <[email protected]>

<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>

Subject: Re: Console app freezes
Date: Mon, 20 Dec 2004 17:59:01 -0800
Lines: 193
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: text/plain;
charset="Utf-8"
Content-Transfer-Encoding: 8bit
X-Newsreader: Microsoft CDO for Windows 2000
Content-Class: urn:content-classes:message
Importance: normal
Priority: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
Newsgroups: microsoft.public.dotnet.framework.compactframework
NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.1.29
Path: cpmsftngxa10.phx.gbl!TK2MSFTFEED02.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGXA0
3.phx.gbl
Xref: cpmsftngxa10.phx.gbl microsoft.public.dotnet.framework.compactframework:67300
X-Tomcat-NG: microsoft.public.dotnet.framework.compactframework

WaitCommEvent() is actually a P/invoke method which calls the Win API's
(coredll.dll) WaitCommEvent() method. Quoting the MSDN: "This function waits
for an event to occur for a specified communications device. The set of
events that are monitored by WaitCommEvent is contained in the event mask
associated with the device handle."

Would calling WaitCommEvent be a problem?

I will see if i can use a circular buffer. Thanks.

What's in WaitForCommEvent()? It's not a while loop which checks for some
variable set from event, is it?

I would also suggest using circular buffer instead of creating new array
lists and arrays for every packet.
You'll need to firure out what to do in case buffer overflows (terminate,
log event, ignore extra data, etc.).

Best regards,

Ilya

This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------
Thread-Topic: Console app freezes
thread-index: AcTm7jZvbF/weKNQT22YrExp4stGvg==
X-WBNR-Posting-Host: 202.6.138.45
From: "=?Utf-8?B?TWljaGFlbC0tSg==?="

References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
Subject: Re: Console app freezes
Date: Mon, 20 Dec 2004 15:47:06 -0800
Lines: 116
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: text/plain;
charset="Utf-8"
Content-Transfer-Encoding: 8bit
X-Newsreader: Microsoft CDO for Windows 2000
Content-Class: urn:content-classes:message
Importance: normal
Priority: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
Newsgroups: microsoft.public.dotnet.framework.compactframework
NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.1.29
Path: cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl
Xref: cpmsftngxa10.phx.gbl
microsoft.public.dotnet.framework.compactframework:67289
X-Tomcat-NG: microsoft.public.dotnet.framework.compactframework

My app uses OpenNETCF.org’s serial comms code with a few modifications
in
their Port.cs class. This class simply sets up a thread called
‘CommEventThread’ that continually loops the associated com port for
data.
However, I had to modify this to reflect the modifications I made to the
lower level serial drivers. The serial drivers were changed such that it
suited the data it was processing. The data was basically composed of
packets
separated by parity errors. I couldn’t use a parity error event to
distinguish between packets because the app couldn’t keep up with the
number
of parity error events being raised. Instead, I modified the serial
driver
such that it places an escape ‘f0’ character in the receive stream
whenever
it detected a parity error and my app simply needed to locate this à ¢â‚¬Ëœ
f0’
character. To distinguish between an escape ‘f0’ character between an
actual
data ‘f0’, I replaced the data one with a 6-byte signature which my
higher
level app also searches for. So in pseudo code, this is how the
CommEventThread in Port.cs looks like:

private void CommEventThread()
{
while(hPort != invalidHandle)
{

// Wait for a comm event to take place;
WaitForCommEvent();

if(error event)
{
// Handle error;
}

if(data received)
{
do
{
ReadFile() to rxFIFO buffer;
}while(bytesread > 0)
}

while(rxFIFO.Count > 0)
{
byte u = rxFIFO.Dequeue();

if(u == any byte)
{
// Add ‘u’ to progressBuffer ArrayList
progressBuffer.Add(u);
}

if(u == ‘f0’)
{
// Raise ParityError() event and clear progressBuffer;
ParityError();
progressBuffer = new ArrayList();
}

if(u is part of 6-byte signature)
{
// Take note of it;
}

if(u is last byte of 6-byte signature)
{
// Insert ‘f0’ in the data;
progressBuffer.Add(u);
}
}
}
}

I also added the method ReadProgressBuffer() in Port.cs which gets the
current progressBuffer contents when a parity error event is raised. This
will be called by my main app.

public byte[] ReadProgressBuffer(){
return (byte[])progressBuffer.ToArray(typeof(byte));
}

In my main code, I instantiate 4 port objects which means that I
introduce 4
CommEventThreads executing the above code in non-stop looping. My main
also
handles the ParityError events raised by each port by creating 4
indentical
event handlers that process the data by firstly calling
portX.ReadProgressBuffer(). Below is the pseudo code:

private void portX_ParityError()
{
byte[] packet = portX.ReadProgressBuffer();

// Process the byte array here;
// This predominantly involves packet validation -
// CRC checks, and updating a set of global data;
}

When this handler returns, the CommEventThread continues by clearing the
progressBuffer and repeating the whole process.

In addition to this, I have 3 timers, TCP/IP stuff, and log keeping (as
described in my first post). Would it definitely be a CPU overload issue?
If
you need more information regarding my app or any of its code, please
feel
free to ask. Thanks again.


:

This behavior seem to be a result if excessive CPU load.
Do you have some tight loops anywhere? Say, waiting for something?
Do you know what your app will do in case more data is coming from
serial
port(s) than can be processed?
Could it wait for available buffer in a loop without sleep() in it?
That would cause the "serial" thread to use 100% CPU, which would slow
down
all other thread, which would slow down data processing, which would
cause
"serial" thread to wait... and so on. As you remove incoming data, your
app
would eventually process data and unlock itself.

Best regards,

Ilya

 

[Ilya Tumanov [MS]]

Oh, boy... I wish we can add some pin toggling code in key places, attach
an oscilloscope and see all timing relations right away like I used to do
back in my firmware development days... Too bad, that's probably not an
option.

Anyway, I'm starting to wonder if it's a simple case of performance
problem. Geode@300 MHz is probably slower than 200MHz ARM.
To make things worse, CF V1 is very slow on x86. Any chance you can try it
on CF V2 (released with VS 2005 Beta)? It's way, way faster.
Your app should run without recompilation (with config file if you have V1
in ROM).

We can't rule out thread interaction issues as well, however.
Can you disable all threads (or do nothing in them) but one serial thread
and see if it can handle, say, 200 packets per second?

Best regards,

Ilya

This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------

Thread-Topic: Console app freezes
thread-index: AcTnCQZq3JeJx5bQS7aDw22pv2S38w==
X-WBNR-Posting-Host: 202.6.138.45
From: "=?Utf-8?B?TWljaGFlbC0tSg==?=" <[email protected]>
References: <[email protected]>

<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>

Subject: Re: Console app freezes
Date: Mon, 20 Dec 2004 18:59:02 -0800
Lines: 287
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: text/plain;
charset="Utf-8"
Content-Transfer-Encoding: 8bit
X-Newsreader: Microsoft CDO for Windows 2000
Content-Class: urn:content-classes:message
Importance: normal
Priority: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
Newsgroups: microsoft.public.dotnet.framework.compactframework
NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.1.29
Path: cpmsftngxa10.phx.gbl!TK2MSFTNGXA02.phx.gbl!cpmsftngxa06.phx.gbl!TK2MSFTNGP08
.phx.gbl!TK2MSFTNGXA03.phx.gbl
Xref: cpmsftngxa10.phx.gbl microsoft.public.dotnet.framework.compactframework:67304
X-Tomcat-NG: microsoft.public.dotnet.framework.compactframework

At the moment, i open all 4 comports but i'm only giving serial input to 2
ports (1 & 3). When i had 20 packets/sec going into each port1 and port3, the
app worked fine (40 packets/sec total). When i increased that to 30
packets/sec each (60 packets/sec total) the app would "freeze" after a while.
Increasing it to 40 packets/sec each (80 packets/sec total) also made it
"freeze".

I then decided to test the app with only one port processing serial input. I
used port1 and inputted 80 packets/sec. It worked fine. There's some kind of
serious threading issue happening and i can't seem to pinpoint it.

Also, i am using System.Threading timers. Thanks.

No, it should not cause problems as it would release ticks to OS while
waiting.

If you leave only, say, two serial ports, is it working? Is it working if
you discard of serial data without processing it?

About timers: are you using one in Windows.Forms or in System.Threading?

Best regards,

Ilya


This posting is provided "AS IS" with no warranties, and confers no rights.


--------------------

Thread-Topic: Console app freezes
thread-index: AcTnAKQ4g7fe4r2XTIeutiQV26gjCw==
X-WBNR-Posting-Host: 202.6.138.45
From: "=?Utf-8?B?TWljaGFlbC0tSg==?="

References: <[email protected]>

<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>

Subject: Re: Console app freezes
Date: Mon, 20 Dec 2004 17:59:01 -0800
Lines: 193
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: text/plain;
charset="Utf-8"
Content-Transfer-Encoding: 8bit
X-Newsreader: Microsoft CDO for Windows 2000
Content-Class: urn:content-classes:message
Importance: normal
Priority: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
Newsgroups: microsoft.public.dotnet.framework.compactframework
NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.1.29
Path:

cpmsftngxa10.phx.gbl!TK2MSFTFEED02.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGXA0
3.phx.gbl

Xref: cpmsftngxa10.phx.gbl microsoft.public.dotnet.framework.compactframework:67300
X-Tomcat-NG: microsoft.public.dotnet.framework.compactframework

WaitCommEvent() is actually a P/invoke method which calls the Win API's
(coredll.dll) WaitCommEvent() method. Quoting the MSDN: "This

function
waits

for an event to occur for a specified communications device. The set of
events that are monitored by WaitCommEvent is contained in the event mask
associated with the device handle."

Would calling WaitCommEvent be a problem?

I will see if i can use a circular buffer. Thanks.

:

What's in WaitForCommEvent()? It's not a while loop which checks

for
some

variable set from event, is it?

I would also suggest using circular buffer instead of creating new array
lists and arrays for every packet.
You'll need to firure out what to do in case buffer overflows (terminate,
log event, ignore extra data, etc.).

Best regards,

Ilya

This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------
Thread-Topic: Console app freezes
thread-index: AcTm7jZvbF/weKNQT22YrExp4stGvg==
X-WBNR-Posting-Host: 202.6.138.45
From: "=?Utf-8?B?TWljaGFlbC0tSg==?="

References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
Subject: Re: Console app freezes
Date: Mon, 20 Dec 2004 15:47:06 -0800
Lines: 116
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: text/plain;
charset="Utf-8"
Content-Transfer-Encoding: 8bit
X-Newsreader: Microsoft CDO for Windows 2000
Content-Class: urn:content-classes:message
Importance: normal
Priority: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
Newsgroups: microsoft.public.dotnet.framework.compactframework
NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.1.29
Path: cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl
Xref: cpmsftngxa10.phx.gbl
microsoft.public.dotnet.framework.compactframework:67289
X-Tomcat-NG: microsoft.public.dotnet.framework.compactframework

My app uses OpenNETCF.org’s serial comms code

with a few
modifications

in
their Port.cs class. This class simply sets up a thread called
‘CommEventThread’ that continually

loops the associated
com port for

data.
However, I had to modify this to reflect the modifications I made

to
the

lower level serial drivers. The serial drivers were changed such

that
it

suited the data it was processing. The data was basically composed of
packets
separated by parity errors. I couldn’t use a

parity error
event to

distinguish between packets because the app couldnâ€â„

¢t keep up
with the

number
of parity error events being raised. Instead, I modified the serial
driver
such that it places an escape ‘f0’

character in the
receive stream

whenever
it detected a parity error and my app simply needed to locate

this Ã
¢â‚¬Ëœ

f0’
character. To distinguish between an escape ‘f0âÃ

¢â€šÂ¬Ã¢â€žÂ¢
character between an

actual
data ‘f0’, I replaced the data one

with a 6-byte
signature which my

higher
level app also searches for. So in pseudo code, this is how the
CommEventThread in Port.cs looks like:

private void CommEventThread()
{
while(hPort != invalidHandle)
{

// Wait for a comm event to take place;
WaitForCommEvent();

if(error event)
{
// Handle error;
}

if(data received)
{
do
{
ReadFile() to rxFIFO buffer;
}while(bytesread > 0)
}

while(rxFIFO.Count > 0)
{
byte u = rxFIFO.Dequeue();

if(u == any byte)
{
// Add ‘u’ to progressBuffer ArrayList
progressBuffer.Add(u);
}

if(u == ‘f0’)
{
// Raise ParityError() event and clear progressBuffer;
ParityError();
progressBuffer = new ArrayList();
}

if(u is part of 6-byte signature)
{
// Take note of it;
}

if(u is last byte of 6-byte signature)
{
// Insert ‘f0’ in the data;
progressBuffer.Add(u);
}
}
}
}

I also added the method ReadProgressBuffer() in Port.cs which

gets
the

current progressBuffer contents when a parity error event is

raised.
This

will be called by my main app.

public byte[] ReadProgressBuffer(){
return (byte[])progressBuffer.ToArray(typeof(byte));
}

In my main code, I instantiate 4 port objects which means that I
introduce 4
CommEventThreads executing the above code in non-stop looping. My main
also
handles the ParityError events raised by each port by creating 4
indentical
event handlers that process the data by firstly calling
portX.ReadProgressBuffer(). Below is the pseudo code:

private void portX_ParityError()
{
byte[] packet = portX.ReadProgressBuffer();

// Process the byte array here;
// This predominantly involves packet validation -
// CRC checks, and updating a set of global data;
}

When this handler returns, the CommEventThread continues by

clearing
the

progressBuffer and repeating the whole process.

In addition to this, I have 3 timers, TCP/IP stuff, and log

keeping
(as

described in my first post). Would it definitely be a CPU

overload
issue?

If
you need more information regarding my app or any of its code, please
feel
free to ask. Thanks again.


:

This behavior seem to be a result if excessive CPU load.
Do you have some tight loops anywhere? Say, waiting for something?
Do you know what your app will do in case more data is coming from
serial
port(s) than can be processed?
Could it wait for available buffer in a loop without sleep() in it?
That would cause the "serial" thread to use 100% CPU, which

would
slow

down
all other thread, which would slow down data processing, which would
cause
"serial" thread to wait... and so on. As you remove incoming

data,
your

app
would eventually process data and unlock itself.

Best regards,

Ilya

 

[Guest]

That's a very good question. I kept telling myself the same thing as I
was debugging my communication library. The dll itself didn't have any
windows forms code in it either, though admittedly it was used from a
graphical program.

Basically what I did was (semi-psudo code):

While ElapsedTime < RcvTimeout

If Sock.Available <> 0 Then

If ProcessSocket() = True Then Return

Else 'no data on the wire

Windows.Forms.Application.DoEvents()
System.Threading.Thread.Sleep(SLEEP_AMT)
ElapsedTime = (DateTime.Now.Ticks - StartTicks) /
TICKS_PER_MILLISECOND

End If

Loop

This was extracted and simplified from code that runs in the
communications thread.

Tom C.

 

[Guest]

Hi Ilya,

Sorry for not replying in a while. I think you were correct when you said
that this was a perf problem.

To find out, I commented out all the packet processing code for each port
and simply let the app just decode packets. Inputting 60 packets/sec to two
ports (120 packets/sec total), the app ran like a charm. And so i thought,
why not add a bit of packet processing code at a time and see where it
cracks. So that's what i did and i discovered that the main cause for the
"freezing" were a particular few statements. Uncommenting them caused
freezing, commenting them did not. So i found a more optimized way to carry
out the statements and the app works fine now.

With regards to CFv2, is there any way of using that without having VS.NET
2005? Yes, i have CFv1 in my ROM OS image. Thanks a lot.

Michael--J.

 

[Ilya Tumanov [MS]]

I'm glad you solved this problem.

As to your question, CF V2 is currently in beta 1 (beta 2 to be released
soon) and it's only available within VS 05 Beta (which you could get for
free).

However, released version of CF V2 should be included into free SDK, so,
yes; you'll be able to develop for it without VS (command line only, no
IDE).
Also, PB QFE is planned, so you'll be able to build an image with CF V2 in
ROM.

Compatibility with V1 is a high priority, so there's a good chance you'll
be able to run V1 application on V2 directly.
If not, we will appreciate feedback from your (and anybody else) on V1/V2
incompatibilities so they can be investigated and fixed.

Best regards,

Ilya

This posting is provided "AS IS" with no warranties, and confers no rights.


--------------------

Thread-Topic: Console app freezes
thread-index: AcTuAUGzNa6+I/coR4Sx5KXyCaiYsg==
X-WBNR-Posting-Host: 202.6.138.45
From: "=?Utf-8?B?TWljaGFlbC0tSg==?=" <[email protected]>
References: <[email protected]>

<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>

Subject: Re: Console app freezes
Date: Wed, 29 Dec 2004 15:51:03 -0800
Lines: 44
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: text/plain;
charset="Utf-8"
Content-Transfer-Encoding: 7bit
X-Newsreader: Microsoft CDO for Windows 2000
Content-Class: urn:content-classes:message
Importance: normal
Priority: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
Newsgroups: microsoft.public.dotnet.framework.compactframework
NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.1.29
Path: cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl
Xref: cpmsftngxa10.phx.gbl microsoft.public.dotnet.framework.compactframework:67729
X-Tomcat-NG: microsoft.public.dotnet.framework.compactframework

Hi Ilya,

Sorry for not replying in a while. I think you were correct when you said
that this was a perf problem.

To find out, I commented out all the packet processing code for each port
and simply let the app just decode packets. Inputting 60 packets/sec to two
ports (120 packets/sec total), the app ran like a charm. And so i thought,
why not add a bit of packet processing code at a time and see where it
cracks. So that's what i did and i discovered that the main cause for the
"freezing" were a particular few statements. Uncommenting them caused
freezing, commenting them did not. So i found a more optimized way to carry
out the statements and the app works fine now.

With regards to CFv2, is there any way of using that without having VS.NET
2005? Yes, i have CFv1 in my ROM OS image. Thanks a lot.

Michael--J.

Oh, boy... I wish we can add some pin toggling code in key places, attach
an oscilloscope and see all timing relations right away like I used to do
back in my firmware development days... Too bad, that's probably not an
option.

Anyway, I'm starting to wonder if it's a simple case of performance
problem. Geode@300 MHz is probably slower than 200MHz ARM.
To make things worse, CF V1 is very slow on x86. Any chance you can try it
on CF V2 (released with VS 2005 Beta)? It's way, way faster.
Your app should run without recompilation (with config file if you have V1
in ROM).

We can't rule out thread interaction issues as well, however.
Can you disable all threads (or do nothing in them) but one serial thread
and see if it can handle, say, 200 packets per second?

Best regards,

Ilya

This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------