Re: [Bacnet-developers] Win32 Port - Timing problems?

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Hi Peter,

I was following a very similar thinking with my debugging yesterday and
I think I may have isolated at least part of the cause. In the receive
FSM task, it seems to me that if the...
While(True)
	if ((MSTP_Port.ReceivedValidFrame == false) &&
		(MSTP_Port.ReceivedInvalidFrame == false)) {...more code
here...}
}
...if statement evaluates false (ie some sort of data has been
received), that the receive FSM can enter a tight loop. I guess at this
point the scheduling should kick in and give the other tasks a chance to
process the information and set the given flag back to false, while the
receive FSM is in the tight loop (or does the task have to specifically
yeild? because that doesn't look like it happens). Because for some
reason it doesn't seem to (any ideas?).

In any case, adding an else clause to this statement which contains a
sleep(1) seems to have fixed the problem in my case. By forcing the
receive FSM to yeild the processor and allow the other tasks to deal
with the data. Unless of course my logic is flawed and it is another
side effect of the sleep(1) that is solving the problem.

I'm still unsure how the comm port fitted into all of this. Because
during some of my debugging the program seemed to be stuck in ReadFile()
and another task was in WriteFile() waiting for the read to finish when
I stopped the execution to see what was going on. This could have been
because the program was in this state the majority of the time because
the read timeouts on the comm port were quite long (at least 1000ms). So
everything that accessed the comm port was waiting for this timeout if
no data was being received, due to the port being syncronous. I've
shortened the read timeouts on the comm ports anyway, to something I
figure is a little more reasonable.

Kind Regards,
Mills

-----Original Message-----
From: pe...@se... [mailto:pe...@se...] 
Sent: Wednesday, 10 February 2010 2:04 AM
To: Discussion for developers of the BACnet stack
Subject: Re: [Bacnet-developers] Win32 Port - Timing problems?

Hi Mills,

I'm not too familiar with the tasking modle for Windows threads but I
notice the 3 tasks are all set up with the same very high priority
(preseumably in an attempt to get Windows to "play nice" with them and
let them get called without too much latency) my suspicions are that
somewhere in all this one of the tasks is not yielding and somehow
stopping the round robin scheduling that is supposed to happen with
equal priority tasks. Why others haven't reported this issue I'm not
sure.

If the sleeps() work for you that may be sufficent to get you going but
I would be uncomfortable with just masking an issue without fully
understanding where it is coming from.

Have you tried using the Borland compiler or Visual Studio Express 2008
(both freely
available) to build the app and seeing if the problem is still there?
I've done most of my testing with VS 2008 and ocasionally built them
with the Borland compiler but I've been using BACnet/IP only for the
moment talking to my port of the stack running on Rabbits BL4S100 SBC
(when I have some Rabbit boards with RS485 I may try and implement the
MS/TP interface as well).

Regards,
Peter

On 9 Feb 2010 at 12:57, Mills, Clayton (GE EntSol, Security, consuRe:
[Bacnet-developers]
Win32 Port - Timing probl wrote:

> Hi again,
> 
> In response to your questions,
> 
> 1. Win XP SP2
> 2. gcc version 3.4.5 (mingw)
> 3. Celeron 2.53GHz single core
> 
> During my continued debugging I replaced the print statements with
> sleep() commands and this also seemed to fix the problem.
> 
> I'm starting to think that the problem is somehow related to the 
> receive FSM hogging resources, especially the serial port as a
resource.
> 
> I'm currently looking into the RS485/Comm Port configuration status. 
> I'm thinking that perhaps the read timeouts could be causing the issue

> and making the program hang in ReadFile() for extended amounts of 
> time. I'll keep looking and no doubt report back with anything I find.
> 
> Thanks for your input Peter. Really at this point I'm a bit stumped, 
> so this is exactly the sort of thing I was looking for. A fresh angle,

> questions and having to think about whats going on to answer them, 
> might in the end yeld the correct answer.
> 
> Kind Regards,
> Mills
> 
> -----Original Message-----
> From: pe...@se... [mailto:pe...@se...]
> Sent: Monday, 8 February 2010 9:48 PM
> To: bac...@li...
> Subject: Re: [Bacnet-developers] Win32 Port - Timing problems?
> 
> Hi Mills,
> 
> I haven't tried to use the Windows MS/TP code yet so I am probably 
> shooting in the dark but there are a couple of questions to ask just 
> to get some more background info:
> 
> 1. What version of Windows are you using?
> 2. What Compiler and version are you using?
> 3. What type of cpu is in your PC (single core/multiple core)?
> 
> I'd be surprised if it was just timing related - have you tried 
> replacing the printfs with simple delay loops?
> 
> A couple of possible thiings to check would be:
> 
> The fact that calling fprintf, apart from taking more time, will also 
> result in system calls which may have an impact on task switching.
> 
> I don't know what impact multiple processors would have (if any) on 
> the code in question.
> 
> Again, I'm shooting in the dark here but perhaps the questions may
help!
> 
> Regards,
> Peter
> 
> On 8 Feb 2010 at 11:00, Mills, Clayton (GE EntSol, Security, 
> consu[Bacnet-developers]
> Win32 Port - Timing problems? wrote:
> 
> > 
> > Hi,
> > 
> > I've been working with the bacnet stack code for acouple ofweeks 
> > now, getting MSTP over
> > RS485 working on an AT91SAM7X and am now trying to get the win32 
> > port working so that I can communicate between my embedded device 
> > and my desktop. I am however running into some problems that seem to

> > be a little odd, so was wondering if anyone else has seen any 
> > similar
> problem.
> > 
> > Essentially when I compiled and configured everything, the code was 
> > not sending anything over serial, so I started debugging the
problem.
> > I eventually found that the serial port is configured and connected
> correctly and that the problem seems to be some sort of timing issue.
> > 
> > I came to this conclusion when I added a debug fprintf statement to 
> > each of thethe master and recieve FSM thread tasksof dlmstp.c in 
> > their
> 
> > "forever loop". This was in functions dlmstp_master_fsm_task(void
> > *pArg) and dlmstp_receive_fsm_task(void *pArg). The addition of 
> > these fprintf statements fixed the problem andthe CRO attached to my

> > serial
> port started seeing poll for master frames being transmitted over the 
> serial connection.
> > 
> > I unzipped a new copy of bacnet stack codeand tried adding these 
> > statements again, thinking that I must have changed something else 
> > to fix the problem. But it seems that the delay added by the print
> statements is indeed what fixes my problem, though what causes the 
> problem escapes me.
> > Especially as I haven't made any other modifications to the code.
> > 
> > I have also tried the dlmstp-mm.c code, and encounter the same
> problem.
> > 
> > Has anyone encountered anything like this before? Any ideas on a
> solution?
> > 
> > Kind Regards,
> > Clayton H Mills
> > 
> > 
> > DISCLAIMER:
> > This e-mail and any attachment is intended only for the exclusive 
> > and confidential use of the addressee(s). If you are not the 
> > intended recipient, any use, interference with, disclosure or 
> > copying of this material is unauthorised and prohibited. If you have

> > received this message in error, please notify the sender by return 
> > e-mail immediately and delete the message from your computer without

> > making any copies. Please see http://www.ge.com/privacy.html for 
> > information about our privacy practices
> 
> 
> 
> 
> ----------------------------------------------------------------------
> --
> ------
> The Planet: dedicated and managed hosting, cloud storage, colocation 
> Stay online with enterprise data centers and the best network in the 
> business Choose flexible plans and management services without 
> long-term contracts Personal 24x7 support from experience hosting pros

> just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> BACnet-developers mailing list
> BAC...@li...
> https://lists.sourceforge.net/lists/listinfo/bacnet-developers
> 
> 
> DISCLAIMER:
> This e-mail and any attachment is intended only for the exclusive and
confidential use of the addressee(s). If you are not the intended
recipient, any use, interference with, disclosure or copying of this
material is unauthorised and prohibited. If you have received this
message in error, please notify the sender by return e-mail immediately
and delete the message from your computer without making any copies.
Please see http://www.ge.com/privacy.html for information about our
privacy practices.
> 
> ----------------------------------------------------------------------
> -------- The Planet: dedicated and managed hosting, cloud storage, 
> colocation Stay online with enterprise data centers and the best 
> network in the business Choose flexible plans and management services 
> without long-term contracts Personal 24x7 support from experience 
> hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> BACnet-developers mailing list
> BAC...@li...
> https://lists.sourceforge.net/lists/listinfo/bacnet-developers
> 

------------------------------------------------------------------------
------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the
business Choose flexible plans and management services without long-term
contracts Personal 24x7 support from experience hosting pros just a
phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
BACnet-developers mailing list
BAC...@li...
https://lists.sourceforge.net/lists/listinfo/bacnet-developers

DISCLAIMER:
This e-mail and any attachment is intended only for the exclusive and confidential use of the addressee(s). If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this message in error, please notify the sender by return e-mail immediately and delete the message from your computer without making any copies. Please see http://www.ge.com/privacy.html for information about our privacy practices.