I know this is a loaded question, but is there really any actual date defined for the release of V4.2?
I am having so much trouble with the current Beta, that I just cant imagine it being any time this year.
Unfortunately I have only a few weeks left to finish my product, and I just can't afford the time I waste every day with deployment issues. it may be ok for a hobbiest, but for a comercial application like mine, it is costing far too much in lost time. I chose the Netduino against the wishes of my superiors, because I can see that it will be a fantastic platform one day. But right now I think I'll be retiring before I see that happen.
Today I kept a record, and over 4 hours was wasted over the course of a day with deployment issues, that would constantly stop me in my tracks.
I don't know what it is that triggers them, nor do I know the magic formula for getting it going again, but it involves everything up to and including rebooting the PC and manually erasing the Netduino.
I just can't wait any longer, and I'm going to have to find another solution.
My only hope is a positive response to this post, and a new much more stable version within a week.
So what are the chances?
Regards
Rohan
When will V4.2 really be released and working?
Started by rhamer, Jun 14 2012 10:44 AM
24 replies to this topic
#2
nakchak
-
- Members
-
- 404 posts
Advanced Member
- LocationBristol, UK
Posted 14 June 2012 - 11:07 AM
I generally find that if it gets stuck deploying, as long as i cancel the deployment in VS, unplug the USB lead then reconnect it, 9 times out of 10 that fixes the issue, failing that doing the same thing and restarting VS always works for me.
The real killer is when i forget to cancel deployment and press the reset button or yank the lead and get the BSOD.
I to have lost many hours of commercial development time to this issue, just seems there is no sure fire way of reproducing the issue, that said i have a VHD which i can crash fairly reliably on my work and home pc's, although i dont know if that it more to do with the VM than anything else, and of course my superiours don't want me fault finding deployment issues when they pay me to code...
Nak.
#3
mastronic
-
- Members
-
- 13 posts
Member
- LocationFrench - France (Lille)
Posted 14 June 2012 - 05:28 PM
I think it comes from your program.
I also had a moment or you may not access deployment. When unplug the USB , pc is reboot automatiquely ! (driver problem? OS windows 7 Pro 64-bit + NetduinoPlus + 4.2 framework).
I think I found the reason (one reason may be). The way of coded .. I declared a variable within a program interuption (who often call themselves). I exit out of the variable this function and I solved the problem.
I think it comes from the action of the watchdog when the memory decreases. The watchdog seems slow.
my English is poor, sorry if not understand.
Thierry
#4
nakchak
-
- Members
-
- 404 posts
Advanced Member
- LocationBristol, UK
Posted 14 June 2012 - 06:44 PM
Tight loops can cause issues, but the whole BSOD issue smacks of issues with the driver, for me its the BSOD that is the worst issue, i can cope with unplugging/power cycling the device but invarably you will BSOD when you are in the middle or replying to an email or something similar, and as rhamer alludes to when you are doing commercial development that is lost time, and when deadlines loom you really want to focus on bug fixes not low level transport/deployment issues.
#5
Valkyrie-MT
-
- Members
-
- 315 posts
Advanced Member
- LocationIndiana, USA
Posted 14 June 2012 - 08:05 PM
I generally find that if it gets stuck deploying, as long as i cancel the deployment in VS, unplug the USB lead then reconnect it, 9 times out of 10 that fixes the issue, failing that doing the same thing and restarting VS always works for me.
I do the exact same thing and I manage to be fairly productive. Also, at the beginning of my program, I turn on the onboard LED, then sleep for 10 seconds when in debug mode. This makes sure that the Netduino does not immediately go into a tight loop when it restarts and allows the app to load successfully more often... The LED turning on is my signal to hit the run button in Visual Studio.
-Valkyrie-MT
#6
rhamer
-
- Members
-
- 29 posts
Member
- LocationMelbourne Australia
Posted 14 June 2012 - 11:18 PM
Well I feel a little better now that I have found some brothers that understand my pain.
I really dont want to move away from the Netduino, but given these issues are obviously not just with my environment, I don't hold out much of a chance of me being able to fix them.
I am however interested in the various solution that have been offered up, and perhaps between us we can figure out the magic formula to type, chant, drink or whatever actually works. Hell I'll even turn my whole desk to face east if that proves to be the key.
I am going to start another thread where we can all share out little tips and tricks on solving the deployment issues we are all having.
However I don't want this thread to end, I really want an answer from Secret Labs to my initial question, and some sort of acknowledgement that these problems are not just annoyances, they are show stoppingly huge and what is being done about them for real.
Regards
Rohan
#7
Arbiter
-
- Members
-
- 132 posts
Advanced Member
- LocationBrisbane, Australia
Posted 15 June 2012 - 12:32 AM
I found that pressing the reset button on the N+ during a stuck deployment also causes an abrupt reboot of the PC host.
My apps have been structured to set up event handlers and timers and then park the "main" thread using Thread.Sleep(Timeout.Infinite). However, some of them have tight polling loops and these are problematic for deployment, as described above by others. I find that deployment is always successful if I shut down all the timers and loops.
To do this, I install a handler on the built-in button. A flag APP_RUN inits to true. The button handler sets it to false. All of the event handlers and loops are coded to loop or restart their timers when this flag is true. Use timers in one-shot mode, it stops overlapping handler calls when they run over time. Restart the timer when the handler is finished - provided that APP_RUN is true. A polling loop like while (APP_RUN) { ... } will obviously exit as soon as the flag is false.
Not only does this make deployment more reliable, it makes it fast.
A couple of unplanned reboots soon teaches you to push the button first! And this is no more a nuisance than unplugging mains equipment before working on it (a belt from 240VAC soon teaches you to unplug first).
My apps have been structured to set up event handlers and timers and then park the "main" thread using Thread.Sleep(Timeout.Infinite). However, some of them have tight polling loops and these are problematic for deployment, as described above by others. I find that deployment is always successful if I shut down all the timers and loops.
To do this, I install a handler on the built-in button. A flag APP_RUN inits to true. The button handler sets it to false. All of the event handlers and loops are coded to loop or restart their timers when this flag is true. Use timers in one-shot mode, it stops overlapping handler calls when they run over time. Restart the timer when the handler is finished - provided that APP_RUN is true. A polling loop like while (APP_RUN) { ... } will obviously exit as soon as the flag is false.
Not only does this make deployment more reliable, it makes it fast.
A couple of unplanned reboots soon teaches you to push the button first! And this is no more a nuisance than unplugging mains equipment before working on it (a belt from 240VAC soon teaches you to unplug first).
One day, all this too shall parse.
#8
nakchak
-
- Members
-
- 404 posts
Advanced Member
- LocationBristol, UK
Posted 15 June 2012 - 08:19 AM
...at the beginning of my program, I turn on the onboard LED, then sleep for 10 seconds when in debug mode. This makes sure that the Netduino does not immediately go into a tight loop when it restarts and allows the app to load successfully more often... The LED turning on is my signal to hit the run button in Visual Studio.
I install a handler on the built-in button. A flag APP_RUN inits to true. The button handler sets it to false. All of the event handlers and loops are coded to loop or restart their timers when this flag is true. Use timers in one-shot mode, it stops overlapping handler calls when they run over time. Restart the timer when the handler is finished - provided that APP_RUN is true. A polling loop like while (APP_RUN) { ... } will obviously exit as soon as the flag is false.
Those are both really nice solutions, im wondering if a combination of the 2 approaches using a debug build statement could be refactored into a generic base class/vs project template that would save a lot of pain and be quite a light touch
And this is no more a nuisance than unplugging mains equipment before working on it (a belt from 240VAC soon teaches you to unplug first).
Too true, you quickly learn what the pain of a thousand rabid hamsters gnawing at your fingers feels like when you make contact for the first time
As for a way to reliably trigger a deployment hang this seems to work for me on any PC (win7 x64) i try it on.
- Deploy code first time no problem
- Deploy code n times no problem
- Stop debugging and restart (either through a reset or power cycle) the ND and let the program run i.e. debug build running in a more production like context
- Try and redeploy/attach debugger, deploy hangs reseting or unplugging ND causes a BSOD (windbg analysis says either memory corruption or vista driver error) waiting about 5 mins raises a deployment error dialog in vs...
Nak.
#9
Arbiter
-
- Members
-
- 132 posts
Advanced Member
- LocationBrisbane, Australia
Posted 18 June 2012 - 01:41 AM
I never got the reboot thing from 4.1.0.6, it arrived with 4.2.
Real projects that actually control something are always busy at runtime. The stop-button business made it easier to deploy, so even when Chris figures out what's causing the reboots and fixes it, it would still be worth having a project template that bakes it all in.
I'm considering refactoring so that all the processes that need to be interleaved but don't need true concurrency are cooperatively multitasked à la Win16 on a single "driver" thread that increments an interation counter, with a watchdog on another thread so I can detect a stuck driver and restart the app.
This is something that might lend itself to a mini framework of sorts and that too would profit from being baked into a project template.
One day, all this too shall parse.
#10
rhamer
-
- Members
-
- 29 posts
Member
- LocationMelbourne Australia
Posted 18 June 2012 - 03:18 AM
... As for a way to reliably trigger a deployment hang this seems to work for me on any PC (win7 x64) i try it on.
If other people can hang their deployment that way at least that will be a step towards getting a fix for this issue, as AFAIK its the reproducibility of the issue that is the sticking point on this issue...
- Deploy code first time no problem
- Deploy code n times no problem
- Stop debugging and restart (either through a reset or power cycle) the ND and let the program run i.e. debug build running in a more production like context
- Try and redeploy/attach debugger, deploy hangs reseting or unplugging ND causes a BSOD (windbg analysis says either memory corruption or vista driver error) waiting about 5 mins raises a deployment error dialog in vs...
Nak.
That is pretty much the trigger for me as well.
Going on what others have said here, it appears to be when the program is executing on it's own you cant break into it to deploy another.
something else I have also seen is, it sort of half deploys before failing and leaves the Netduino no longer able to receive a new deployment, or even free run the old one, even with the USB disconnected and power cycled.
I have seen this because my project has an LCD screen for output and during the program init it writes a few lines of stuff. When it gets half updated, I only get some of the text on the screen, and the netduino just appears to freeze, even ignoring the reset button sometimes.
Regards
Rohan
#11
Arbiter
-
- Members
-
- 132 posts
Advanced Member
- LocationBrisbane, Australia
Posted 19 June 2012 - 12:59 PM
Here's a template I knocked up per my earlier description. Give it a whirl and tell me what you think. Couple of key points:
An application watchdog operates at a different level of abstraction to the framework watchdog already present. If you wrote this:
- You only get the kill switch in debug builds. In release builds no handler is attached to the SW1 so it functions as a reset switch.
- In debug builds the watchdog doesn't reboot, it fires an OnStall event which gives you a chance to find out what stalled.
- You have to explicitly register methods for the co-op manager. I had intended to use custom attributes to mark up methods with their intervals and implicitly register them, but NETMF doesn't do custom attributes. The template produces two sample co-op methods to illustrate registration and the required method signature.
- If a co-op task runs for more than a minute the watchdog detects it as stalled.
- Coop mult-tasking only ever runs one logical process at a time so it is effectively single threaded.
- This is an application watchdog.
An application watchdog operates at a different level of abstraction to the framework watchdog already present. If you wrote this:
static void Main() { Thread.Sleep(Timeout.Infinite); }
the built-in watchdog would not detect it because the NETMF framework has not locked up.
Attached Files
-
NetduinoPlusCoopApplication.zip 12.04KB
4 downloads
One day, all this too shall parse.
#12
Chris Walker
-
- Moderators
-
- 7767 posts
Secret Labs Staff
- LocationNew York, NY
Posted 19 June 2012 - 01:30 PM
Hi Rohan,
The reason we haven't taken the firmware out of beta is because .NET MF 4.2 hasn't met our quality criteria yet. The one outstanding issue is the blue screens with the proprietary NETMF driver.
We have been working with Microsoft on the issue since summer 2010. It was actually an issue with .NET MF 4.1, but we created a workaround which fixed the issue most of the time. This workaround no longer works with the changes made in .NET MF 4.2, so both Secret Labs and Microsoft have been doing extensive repro cases to determine the root cause.
After much effort, it was determined that there the issues are driver-related and specific to certain computer+software configurations, and that they seem to affect all .NET MF 4.2-based firmware images using USB to some extent.
So Microsoft is working hard on a new, permanent resolution to the issue. They're replacing the proprietary NETMF drivers with standard WinUSB drivers. WinUSB is a much better solution because it's built into Windows and therefore well-tested across a wide number of devices and computers.
The new WinUSB support is scheduled to be available by mid-July in beta form, and sometime this summer in the QFE2 patch to .NET MF 4.2.
Full details:
http://netmf.codeple...m/workitem/1049
Once the community reports that the QFE2-based WinUSB drivers have fixed the BSOD glitches in relation to .NET MF 4.2, we'll move the Netduino firmware rapidly to RTM.
BTW, we implemented some hardware tweaks in the Netduino Go hardware to reduce the BSOD occurances to .NET MF 4.1 levels (which is why we were able to ship it with .NET MF 4.2 support). We're still not happy with the occurance of any driver crashes, so we're really looking forward to transitioning the full line of USB-capable Netduinos to WinUSB.
Thank you for your patience while Microsoft finishes up their work on the new drivers. So sorry for any pain you are encountering on your computer in relation to .NET MF 4.2 and the beta firmware. We're listening, and many people are working hard behind the scenes to make .NET MF 4.2 a strong platform with RTM firmware.
Chris
P.S.
If you want to switch your Netduino to serial debug/deploy, you can use D0/D1 or D2/D3 and a USB TTL adapter with the 4.2 firmware. You could also use an RS232 shield. This will allow you to write code without any possibility of driver-related BSODs.
So sorry that you're having issues with .NET MF 4.2 and the beta firmware.I know this is a loaded question, but is there really any actual date defined for the release of V4.2?
I don't know what it is that triggers them, nor do I know the magic formula for getting it going again, but it involves everything up to and including rebooting the PC and manually erasing the Netduino.
The reason we haven't taken the firmware out of beta is because .NET MF 4.2 hasn't met our quality criteria yet. The one outstanding issue is the blue screens with the proprietary NETMF driver.
We have been working with Microsoft on the issue since summer 2010. It was actually an issue with .NET MF 4.1, but we created a workaround which fixed the issue most of the time. This workaround no longer works with the changes made in .NET MF 4.2, so both Secret Labs and Microsoft have been doing extensive repro cases to determine the root cause.
After much effort, it was determined that there the issues are driver-related and specific to certain computer+software configurations, and that they seem to affect all .NET MF 4.2-based firmware images using USB to some extent.
So Microsoft is working hard on a new, permanent resolution to the issue. They're replacing the proprietary NETMF drivers with standard WinUSB drivers. WinUSB is a much better solution because it's built into Windows and therefore well-tested across a wide number of devices and computers.
The new WinUSB support is scheduled to be available by mid-July in beta form, and sometime this summer in the QFE2 patch to .NET MF 4.2.
Full details:
http://netmf.codeple...m/workitem/1049
Once the community reports that the QFE2-based WinUSB drivers have fixed the BSOD glitches in relation to .NET MF 4.2, we'll move the Netduino firmware rapidly to RTM.
BTW, we implemented some hardware tweaks in the Netduino Go hardware to reduce the BSOD occurances to .NET MF 4.1 levels (which is why we were able to ship it with .NET MF 4.2 support). We're still not happy with the occurance of any driver crashes, so we're really looking forward to transitioning the full line of USB-capable Netduinos to WinUSB.
Thank you for your patience while Microsoft finishes up their work on the new drivers. So sorry for any pain you are encountering on your computer in relation to .NET MF 4.2 and the beta firmware. We're listening, and many people are working hard behind the scenes to make .NET MF 4.2 a strong platform with RTM firmware.
Chris
P.S.
If you want to switch your Netduino to serial debug/deploy, you can use D0/D1 or D2/D3 and a USB TTL adapter with the 4.2 firmware. You could also use an RS232 shield. This will allow you to write code without any possibility of driver-related BSODs.
#13
Cuno
-
- Members
-
- 144 posts
Advanced Member
- LocationZürich / Switzerland
Posted 19 June 2012 - 07:53 PM
Is that really the only outstanding issue regarding deployment? My impression is that deployment problems exist also with serial deployment, on all NETMF 4.2 and 4.1 implementations that I know. There are at least occasional problems on the Visual Studio side with some state that apparently can become inconsistent, no matter what transport is used. For example, with serial deployment, sometimes deployment fails and often the solution is to switch the transport to USB and immediately back to serial again. So I don't expect all problems to be solved by switching to WinUSB (although this should definitely be a major improvement).The one outstanding issue is the blue screens with the proprietary NETMF driver.
Cuno
#14
rhamer
-
- Members
-
- 29 posts
Member
- LocationMelbourne Australia
Posted 19 June 2012 - 11:40 PM
Hi Rohan,
So sorry that you're having issues with .NET MF 4.2 and the beta firmware.
The reason we haven't taken the firmware out of beta is because .NET MF 4.2 hasn't met our quality criteria yet. The one outstanding issue is the blue screens with the proprietary NETMF driver.
We have been working with Microsoft on the issue since summer 2010. It was actually an issue with .NET MF 4.1, but we created a workaround which fixed the issue most of the time. This workaround no longer works with the changes made in .NET MF 4.2, so both Secret Labs and Microsoft have been doing extensive repro cases to determine the root cause.
After much effort, it was determined that there the issues are driver-related and specific to certain computer+software configurations, and that they seem to affect all .NET MF 4.2-based firmware images using USB to some extent.
So Microsoft is working hard on a new, permanent resolution to the issue. They're replacing the proprietary NETMF drivers with standard WinUSB drivers. WinUSB is a much better solution because it's built into Windows and therefore well-tested across a wide number of devices and computers.
The new WinUSB support is scheduled to be available by mid-July in beta form, and sometime this summer in the QFE2 patch to .NET MF 4.2.
Full details:
http://netmf.codeple...m/workitem/1049
Once the community reports that the QFE2-based WinUSB drivers have fixed the BSOD glitches in relation to .NET MF 4.2, we'll move the Netduino firmware rapidly to RTM.
BTW, we implemented some hardware tweaks in the Netduino Go hardware to reduce the BSOD occurances to .NET MF 4.1 levels (which is why we were able to ship it with .NET MF 4.2 support). We're still not happy with the occurance of any driver crashes, so we're really looking forward to transitioning the full line of USB-capable Netduinos to WinUSB.
Thank you for your patience while Microsoft finishes up their work on the new drivers. So sorry for any pain you are encountering on your computer in relation to .NET MF 4.2 and the beta firmware. We're listening, and many people are working hard behind the scenes to make .NET MF 4.2 a strong platform with RTM firmware.
Chris
P.S.
If you want to switch your Netduino to serial debug/deploy, you can use D0/D1 or D2/D3 and a USB TTL adapter with the 4.2 firmware. You could also use an RS232 shield. This will allow you to write code without any possibility of driver-related BSODs.
Hi Chris,
I appreciate the sentiment, but I don't think you really understand the scale of these problems. To be blunt, commercial development against V4.2 is unworkable.
Add to this the annoyance I have when I see talk about other products being designed such as the GO when there are existing products that simply dont work. In my view, any and all available effort should be focused on sorting out the existing issues, rather than new products. All you are going to end up with is a bunch of products that half work, rather than a couple that are really good. i.e exactly how it is now.
There are at least 3 show stopping problems with V4.2 right now.
1/ BSOD
2/ Deployment Fails
3/ VS2010 crashes when hovering over a variable during debugging.
There are probably more, but I cant get past these to see any further.
I know in past posts you have pointed to various problems falling into various camps, but to me I don't care, I just want it fixed. It feels like I'm constantly being told it's not my problem, thats some other guys issue. I dont know what parts fall into who's area and I don't want to. I just want it to work.
I realise I'm being a bit grumpy about this, but you have to realise I'm not in this for the journey, I need to get to the destination as quickly as possible, and that is the suposed main spruking point of .NET MF. I need to use it as part of a robust reliable commercial product, and not some pet egg timer project.
To give you some idea, I have the whole product designed, and prototypes built. In the attached photo of an early prototype you can see that the Netduino is only a small (but significant) part of the project. If I have to scrap it and move to something else, it will be a major setback, but I equally can't continue on this way.
Please can you provide a proper realistic list of known issues and when they will be fixed, with a commitment to sorting out the issues with existing products, before using resources for new development.
BTW I cant use serial for deployment, as I'm using both serial ports as part of the project.
Regards
Rohan
Attached Files
-
IMG_0213.jpg 160.54KB
67 downloads
#15
rhamer
-
- Members
-
- 29 posts
Member
- LocationMelbourne Australia
Posted 19 June 2012 - 11:46 PM
Here's a template I knocked up per my earlier description. Give it a whirl and tell me what you think. Couple of key points:
- You only get the kill switch in debug builds. In release builds no handler is attached to the SW1 so it functions as a reset switch.
- In debug builds the watchdog doesn't reboot, it fires an OnStall event which gives you a chance to find out what stalled.
- You have to explicitly register methods for the co-op manager. I had intended to use custom attributes to mark up methods with their intervals and implicitly register them, but NETMF doesn't do custom attributes. The template produces two sample co-op methods to illustrate registration and the required method signature.
- If a co-op task runs for more than a minute the watchdog detects it as stalled.
- Coop mult-tasking only ever runs one logical process at a time so it is effectively single threaded.
- This is an application watchdog.
An application watchdog operates at a different level of abstraction to the framework watchdog already present. If you wrote this:
static void Main() { Thread.Sleep(Timeout.Infinite); }the built-in watchdog would not detect it because the NETMF framework has not locked up.
Thanks for your effort Arbiter, I will try it out as soon as I can and let you know how I go.
Regards
Rohan
#16
Arbiter
-
- Members
-
- 132 posts
Advanced Member
- LocationBrisbane, Australia
Posted 20 June 2012 - 12:58 AM
You're welcome. I look forward to your feedback, because if people think this is a good architecture then I have a few ideas for improvement. In particular, I was thinking of adopting an approach similar to the way Windows Phone handles stalled tasks.
When a WP7 task runs longer than permitted the it gets a warning to finalise and two seconds after that if it still hasn't yielded it gets terminated and the next task begins.
I think this would work well for tasks that occasionally stall due to environmental factors that change with time. For example, attempting to contact a server depends on carrier network availability which depends on location and load. This is a good example of a case in which killing the stalled task, safe in the knowledge that it will have another go later, is much cleaner than explicit retry logic.
There are a couple of other things I wouldn't mind baking into a project template. Fabien Royer gave me the missing pieces for doing OTAU (over the air updates). The essence of it is explicitly loading an assembly from the SD card; if you have a periodic check for updates on a server and you download them and a config file to the SD card, then you can determine whether your version changed and if so reboot (you can't unload an assembly). The app proper becomes a bootloader that loads an assembly from the SD card according to the content of the config file.
It's conceptually simple but fairly complex in implementation. The bootloader would be pretty much invariant and the whole deployment cycle changes from a push to a pull model. It's a fair bit of work, so I won't do it unless there's interest.
Probably the biggest hassle in OTAU is the need to set up your own update server.
One day, all this too shall parse.
#17
Chris Walker
-
- Moderators
-
- 7767 posts
Secret Labs Staff
- LocationNew York, NY
Posted 20 June 2012 - 04:53 AM
Hi Cuno,
Chris
It's the blocking issue, which is keeping us from taking the 4.2 firmware out of beta. There are a few annoyances that can crop up from time to time which require workarounds...but the BSOD issue is keeping 4.2 marked as beta for the Netduino and Netduino Plus right now. It doesn't seem to occur frequently for the majority of users, but it's a huge issue for the users that it does affect.Is that really the only outstanding issue regarding deployment? My impression is that deployment problems exist also with serial deployment, on all NETMF 4.2 and 4.1 implementations that I know... So I don't expect all problems to be solved by switching to WinUSB (although this should definitely be a major improvement).
Chris
#18
Chris Walker
-
- Moderators
-
- 7767 posts
Secret Labs Staff
- LocationNew York, NY
Posted 20 June 2012 - 05:07 AM
Hi Rohan,
I feel your pain. I too have been waiting very patiently for 4.2 since last summer. For most users, the upgrade to 4.2 is a minor one. But for users who want use lots of memory (and need the new garbage collector scheme) or that use VB, 4.2 is a necessary update.
That said...I would avoid using any beta firmware in production products. I know that you started with 4.2 beta early enough that "it should be RTM by now." We've been working with Microsoft to fix things up so that 4.2 is ready for market. QFE2 will hopefully be the point at which that happens...but in the meantime we can't tell you to use 4.2 beta for production in good conscience.
We've submitted dozens of bug reports to Microsoft, but as much as we speak for a community of 10,000s of developers...each of your individual votes is often as loud as our collective vote. The best way to get resources dedicated to fixing a particular problem is by voting for it at netmf.codeplex.com, the bug repository for .NET MF.
We will continue to fix bugs, both in the Netduino firmware and in the core NETMF PK, as we find them and as they are reported. This is how the SerialPort bugs got fixed, the PWM bugs got fixed, and the garbage collector failure scenarions in 4.1 got identified...through community feedback and open source contributions.
Thank you for that feedback.
I'm told that the WinUSB drivers should be ready for testing in mid-July. We'll adopt them in a beta as soon as possible. If you have a chance to test them, to see if they address most/all of the deployment issues your computer is experiencing, I would really appreciate it. I know that you're trying to develop a product based on beta firmware; let's try to get it out of beta together.
Chris
I feel your pain. I too have been waiting very patiently for 4.2 since last summer. For most users, the upgrade to 4.2 is a minor one. But for users who want use lots of memory (and need the new garbage collector scheme) or that use VB, 4.2 is a necessary update.
That said...I would avoid using any beta firmware in production products. I know that you started with 4.2 beta early enough that "it should be RTM by now." We've been working with Microsoft to fix things up so that 4.2 is ready for market. QFE2 will hopefully be the point at which that happens...but in the meantime we can't tell you to use 4.2 beta for production in good conscience.
First, I just want to make sure: are you experiencing these types of problems with the production firmware? I know that you're using 4.2 beta in this instance. But we're generally very careful to make sure that the production hardware works well and that the production firmware is behaving properly. I'm not speaking about any glitches in Visual Studio...but rather in the actual Netduino hardware/firmware.Add to this the annoyance I have when I see talk about other products being designed such as the GO when there are existing products that simply dont work.
Unfortunately, the BSOD issues are in the NETMF drivers. The deployment failures, when they occur, are either driver-related or related to the .NET MF SDK/PK. And any VS2010 crashes can only be fixed by the Visual Studio team at Microsoft. With the open source bits, we've fixed bugs and continue to do so...but some of this simply cannot be fixed by anyone other than Microsoft.There are at least 3 show stopping problems with V4.2 right now.
1/ BSOD
2/ Deployment Fails
3/ VS2010 crashes when hovering over a variable during debugging.
There are probably more, but I cant get past these to see any further.
I know in past posts you have pointed to various problems falling into various camps, but to me I don't care, I just want it fixed. It feels like I'm constantly being told it's not my problem, thats some other guys issue. I dont know what parts fall into who's area and I don't want to. I just want it to work.
We've submitted dozens of bug reports to Microsoft, but as much as we speak for a community of 10,000s of developers...each of your individual votes is often as loud as our collective vote. The best way to get resources dedicated to fixing a particular problem is by voting for it at netmf.codeplex.com, the bug repository for .NET MF.
I would love it if someone asked Microsoft to stop working on Visual Studio and .NET Micro Framework until all possible bugs were fixed. I know that their top priority is bugfixes. Please open an issue and post your feelings at netmf.codeplex.com. They're there to listen. We'll vote for the issue, and together we can all make .NET MF an even better platform.Please can you provide a proper realistic list of known issues and when they will be fixed, with a commitment to sorting out the issues with existing products, before using resources for new development.
We will continue to fix bugs, both in the Netduino firmware and in the core NETMF PK, as we find them and as they are reported. This is how the SerialPort bugs got fixed, the PWM bugs got fixed, and the garbage collector failure scenarions in 4.1 got identified...through community feedback and open source contributions.
Thank you for that feedback.
I'm told that the WinUSB drivers should be ready for testing in mid-July. We'll adopt them in a beta as soon as possible. If you have a chance to test them, to see if they address most/all of the deployment issues your computer is experiencing, I would really appreciate it. I know that you're trying to develop a product based on beta firmware; let's try to get it out of beta together.
Chris
#19
Arbiter
-
- Members
-
- 132 posts
Advanced Member
- LocationBrisbane, Australia
Posted 20 June 2012 - 05:51 AM
3/ VS2010 crashes when hovering over a variable during debugging.
This is not a showstopper. Use the Locals window.
In my view, any and all available effort should be focused on sorting out the existing issues, rather than new products.
I'd like that too, but it's not realistic. You are asking for a level of product quality not available at this pricepoint. Chris has to balance costs in terms of both time and money; his need to keep products current competes with the very high cost of quality for budget.
I too am trying to make the leap from pet egg timer project to commercial quality. So far, I have found a way around every problem I have encountered. Perfection is unattainable. Robustness in the face of imperfection is possible.
One day, all this too shall parse.
#20
Arbiter
-
- Members
-
- 132 posts
Advanced Member
- LocationBrisbane, Australia
Posted 20 June 2012 - 05:53 AM
1/ BSOD
2/ Deployment Fails
These aren't showstoppers either.
BSOD only occurs during certain types of deployment failure. These deployment failures occur under predictable conditions that can be averted. See earlier posts by me and others.
One day, all this too shall parse.
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users
