I’ve explored every avenue I can. My problem is pretty much identical to this thread. http://www.tinyclr.com/forum/topic?id=5743
These are two of the issues I have encountered - I am not sure if they are related.
My application runs beautifully with the debugger connected - merely by disconnecting the debugger then restarting the hardware it runs like a dog.
I’ve used a variety of code profiling methods but am unable to pinpoint where the problem lies - suffice to say it isn’t occurring within my main loop. The question is - What changes occur with/without the debugger connected? I am unable to find any definitive articles on this.
When setting up an InteruptPort with the trigger InterruptEdgeLow (Or interrupt edge high)
The interrupt event handler continuously fires even though I am neither disabling/re-enabling nor calling ClearInterrupt().
Something (A background process) is using up my precious CPU cycles and it only occurs with the debugger disconnected (after a restart). The problem is so severe that the Interrupt service routine method doesn’t even get called. This occurs even with all debug messages removed. Note - I am doing regular flushes to the LCD from a static bitmap when a graphical change occurs. It’s almost as if something is blocking (which isn’t occurring when the debugger is connected).
I am gradually going insane trying to find cohesive information on .NetMF - Is there a knowledge resource that I am missing?
Any help is much appreciated.
have you tried the thread.sleep(0) as that other discussion found beneficial?
Are there a lot of Debug.Print statements in your program? There have been some comments that implied that Debug.Print statements will slow down the processor if the debugger is not connected.
Mike / Brett,
I’ve already tried thread.sleep(0) in every thread that I create. Difficult to judge if it helps as the performance impact when the debugger is not attached is large. I have also tried removing every single Debug statement in my code - same problem.
I am going to try to create a sample program for the ChipworkX development kit to recreate the issue as I am running on custom hardware with SPI peripherals (No difference when I don’t access them).
The idea that the GC policy differs between having the debugger attached and not is madness. How can one fully debug if the behaviour is different by design? (Not to mention the fact that it doesn’t seem to be clearly documented anywhere)
From a professional standpoint I have the following to add -(Warning - opinionated rant section ahead!)
The use of .NetMF in a professional environment is very difficult to justify. I have experienced vast amounts of regret that I ever embarked upon the project based on the .NetMF hardware in the first place.
This is due to several reasons -
- WPF is dire and glide did not exist at the time - Basically WPF did not fulfil any expectations and I suspect GHI agreed (Hence Glide). I have written my own GUI
- Basic drivers like the TSC2046 touchscreen driver are faulty (They do not read from the touchscreen chip correctly) I have had to write my own driver from scratch.
- Hardware UART handshaking is not supported (making the implementation of RS-485 a nightmare - If I wanted to write C/C++ in RLP I would have bought a platform based on C/C++)
- A lack of documentation - i.e. what functions block - what modules are thread safe etc…
Quite often the solution quoted by many is “Have you tried 4.2?”. Well 4.2 isn’t available for the ChipworkX module; “The most advanced .NET Micro Framework device on the market”, Really? Then why isn’t 4.2 being ported to it. (If there is a technical reason I would love to hear it). It seems that the market is demanding Arduino like products for the home gadgeteer - which the .NetMF platform is very suited to.
I have learned my lesson in quite a painful manner - the use of a still developing system is most definitely not recommended. Early adopter syndrome.
I would love to see this platform become a mature system off which professional developers could base their products. The only reason I haven’t binned it and gone back to good ol’ fashioned C/C++ is because people like Mike and Brett take the time to firefight issues people like myself (a stressed out developer?) encounter.
P.S. I have not slept in a while…
Seeing how you’re working on commercial dev work it might be worth reaching out directly to Gus / GHI and talk through some of your challenges and they can give you the 4.2/Chipworkx story.
You are correct - I will drop Gus a line today. Please don’t misunderstand me though - I am thoroughly impressed with GHIs’ achievements and their dedication to the community. The fact that they went to the effort to develop Glide clearly indicates that they are dedicated to the platform. This has never been in question.
@ Michael8 -
I’ve been developping on Chipworkx for several months now, and never encounter such problems, even when I had to play with several threads…
One of my most important project was HTTP Server + XML Parser over IP + DPWS + TimeService + Screen + smtp client (for an IT Room environnemental display and alert email manager), and everything is fine and powerfull…
Effectively, a piece of code would be fine to help us understand where you’re going wrong…
I have same problem with G400… But for me it’s not a problem, because if you want to use in Release mode your board you have to use this #if statements on Debug.Print functions:
So your compiler in Release mode will not compile Debug.Print that without the debugger goes always in timeout spending a lot of time…
I see this with my GHI400, the touchscreen works great in debug mode, but when I use it in Release mode without #if on debug.print goes extreamely slow…
This is my point of view.
Hope this help.