Sign in

username:

password:



Not a member?

Search rabbit-semi



Search tips

Subscribe to rabbit-semi



Ads

Discussion Groups

See Also

DSPFPGAElectronics

Discussion Groups | Rabbit-Semi | Critical Section


Advertise Here

This is a group for folks designing and programming embedded systems using the Rabbit Semiconductor C-programmable microcontroller. Rabbit Semi is a spin-off from Z-World who makes a variety of embedded modules and tools. This group is not affiliated with either Rabbit or Z-World, but is a user forum for sharing ideas, asking questions, flaunting knowledge, and other typical user group stuff. The Rabbit is a powerful uC, supported by a full-featured C-compiler.

Critical Section - bluetech_th - Oct 28 7:37:45 2009

I have designed a Rabbit system to poll data from RS232 .
Remote PC will poll this data via TCP/IP.
I have one periodical cofunction to read data from RS232 port and store to a register . Another cofunction in another costate read this register and send to PC.

Sometime datas are odd. I don't know why.
Is it possible in critical section for dynamic C ?
anyone have similar problem ?

Sakorn

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



(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )


RE: {Disarmed} Critical Section - Dave McLaughlin - Oct 28 10:11:43 2009

When you say odd, do you mean it is corrupted?

With costates your data should be OK as it is up to your code flow to yield
to the other costate. If you where using UCOS then you would need to use a
semaphore to prevent accessing the same data at the same time.

It would help if you could explain in more detail what the issue with the
data is and what is wrong about it?

I have no issues with using a UCOS based application that reads serial data
in one task and another task is sending this to a file. You just need to
make sure that both tasks are never able to access the same data at the same
time. I am not familiar with costates myself as I use UCOS for all
multi-tasking applications but from reading the manual, they run one at a
time until you yield with a call to a costate wait etc.

Dave...

---
Very funny Scotty, now beam down my clothes!!!
---
http://www.embeddedcomputer.co.uk
---

From: r...@yahoogroups.com [mailto:r...@yahoogroups.com] On
Behalf Of bluetech_th
Sent: 28 October 2009 18:37
To: r...@yahoogroups.com
Subject: {Disarmed} [rabbit-semi] Critical Section

I have designed a Rabbit system to poll data from RS232 .
Remote PC will poll this data via TCP/IP.
I have one periodical cofunction to read data from RS232 port and store to a
register . Another cofunction in another costate read this register and send
to PC.

Sometime datas are odd. I don't know why.
Is it possible in critical section for dynamic C ?
anyone have similar problem ?

Sakorn


(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )

RE: {Disarmed} Critical Section - "Michael Coop (SL4P)" - Oct 28 13:44:37 2009

My guess is that there is aliasing between the socket handler calls and the
query/reply phases of the serial polling.

i.e. for many occurrences

1 send polling query

2 receive reply

3 send via IP,

Loop as required

However if buffer is transient, and the tasks are not phase locked it may
drift to the inevitable.

1 send polling query

2 send via IP, (corrupted data ?)

3 receive reply

Loop as required

MC

From: r...@yahoogroups.com [mailto:r...@yahoogroups.com] On
Behalf Of Dave McLaughlin
Sent: Thursday, 29 October 2009 00:36
To: r...@yahoogroups.com
Subject: RE: {Disarmed} [rabbit-semi] Critical Section

When you say odd, do you mean it is corrupted?

With costates your data should be OK as it is up to your code flow to yield
to the other costate. If you where using UCOS then you would need to use a
semaphore to prevent accessing the same data at the same time.

It would help if you could explain in more detail what the issue with the
data is and what is wrong about it?

I have no issues with using a UCOS based application that reads serial data
in one task and another task is sending this to a file. You just need to
make sure that both tasks are never able to access the same data at the same
time. I am not familiar with costates myself as I use UCOS for all
multi-tasking applications but from reading the manual, they run one at a
time until you yield with a call to a costate wait etc.

Dave...

---
Very funny Scotty, now beam down my clothes!!!
---
http://www.embeddedcomputer.co.uk
---

From: r...@yahoogroups.com [mailto:r...@yahoogroups.com] On
Behalf Of bluetech_th
Sent: 28 October 2009 18:37
To: r...@yahoogroups.com
Subject: {Disarmed} [rabbit-semi] Critical Section

I have designed a Rabbit system to poll data from RS232 .
Remote PC will poll this data via TCP/IP.
I have one periodical cofunction to read data from RS232 port and store to a
register . Another cofunction in another costate read this register and send
to PC.

Sometime datas are odd. I don't know why.
Is it possible in critical section for dynamic C ?
anyone have similar problem ?

Sakorn

______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!



(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )

Re: {Disarmed} Critical Section - bluetech_th - Oct 29 1:34:14 2009

Thank you , for your fast reply.
Yes, data is corrupted , once in a very long time , hardly to emulate .

The critical section problem may come from my sensor, PIC16 device, that use interrupt. I will check my code first.

But I am not sure that cooperative multitasking like Costate and Cofunction of Dynamic C have this problem or not.
If I put a yield command at the right place in cofunction, it should not have a critical section problem, right ?

Sakorn

--- In r...@yahoogroups.com, "Dave McLaughlin" wrote:
>
> When you say odd, do you mean it is corrupted?
>
>
>
> With costates your data should be OK as it is up to your code flow to yield
> to the other costate. If you where using UCOS then you would need to use a
> semaphore to prevent accessing the same data at the same time.
>
>
>
> It would help if you could explain in more detail what the issue with the
> data is and what is wrong about it?
>
>
>
> I have no issues with using a UCOS based application that reads serial data
> in one task and another task is sending this to a file. You just need to
> make sure that both tasks are never able to access the same data at the same
> time. I am not familiar with costates myself as I use UCOS for all
> multi-tasking applications but from reading the manual, they run one at a
> time until you yield with a call to a costate wait etc.
>
>
>
> Dave...
>
> ---
> Very funny Scotty, now beam down my clothes!!!
> ---
> http://www.embeddedcomputer.co.uk
> ---
>
>
>
> From: r...@yahoogroups.com [mailto:r...@yahoogroups.com] On
> Behalf Of bluetech_th
> Sent: 28 October 2009 18:37
> To: r...@yahoogroups.com
> Subject: {Disarmed} [rabbit-semi] Critical Section
>
>
>
>
>
> I have designed a Rabbit system to poll data from RS232 .
> Remote PC will poll this data via TCP/IP.
> I have one periodical cofunction to read data from RS232 port and store to a
> register . Another cofunction in another costate read this register and send
> to PC.
>
> Sometime datas are odd. I don't know why.
> Is it possible in critical section for dynamic C ?
> anyone have similar problem ?
>
> Sakorn
>

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

______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!



(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )

RE: {Disarmed} Re: {Disarmed} Critical Section - Dave McLaughlin - Oct 29 1:55:36 2009

Is your corruption confirmed to be from the use of the costates or could it
be the serial link is corrupted?

Are you using any form of checksum on your serial data? This would allow you
to confirm if there was a failure of the serial data.

With costatement and cofunctions, each task has to yield to the other so any
processing you do on data is safe as it is cooperative multi-tasking. With
the likes of UCOS it is pre-emptive by higher priority tasks even if the
lower task has not yielded in any way.

If you can, output debug information via printf to stdio and this way you
can check to see where the fault is. You can print it out as you receive it
and then in the sending costate, print it out again. It should be the same.
If not, then you have corruption in your handling of the data somewhere. If
you log this window then you can check it later even if your failure is only
every so often. Well worth the effort to track down the issue.

Regards

Dave...

---
Very funny Scotty, now beam down my clothes!!!
---
http://www.embeddedcomputer.co.uk
---

From: r...@yahoogroups.com [mailto:r...@yahoogroups.com] On
Behalf Of bluetech_th
Sent: 29 October 2009 12:33
To: r...@yahoogroups.com
Subject: {Disarmed} Re: {Disarmed} [rabbit-semi] Critical Section

Thank you , for your fast reply.
Yes, data is corrupted , once in a very long time , hardly to emulate .

The critical section problem may come from my sensor, PIC16 device, that use
interrupt. I will check my code first.

But I am not sure that cooperative multitasking like Costate and Cofunction
of Dynamic C have this problem or not.
If I put a yield command at the right place in cofunction, it should not
have a critical section problem, right ?

Sakorn


(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )