7 replies to this topic

[irda]

Hello. I am a beginner and I have seen a lot of examples, but all in debug mode with visual studio. Once you have verified the project and everything is ok, What is the next step to compile and burn my program inside netduino and run on startup? I want to make an application to run at startup without netduino being connected to a PC. Thank you.

[hanzibal]

Apart from compoling for release and maybe remove your Debug.Print statements, the is not much difference if any. Atleast this is how I do it.

[Paul Newton]

Me too. I found that when you stop debugging, the last program you ran is still in the Netduino. (Even after a power cycle or reset.) Paul

[hanzibal]

Also, I think the debugger runs even in release mode, atleast as far as output from Debug.Print which is still included even in release mode.

[Stanislav Husár]

After deploying program to Netduino with Visual Studio, the program remains in Netduino´s flash memory, even after disconnecting Netduino from pc and powering it again. However, you can erase it by deploying another program. So, if you think, that your program is in its final version and ready to use, just remove code used to debug the program, and deploy it from Visual Studio in normal way. Then, if you power Netduino from any power source, it will run program, that was deployed recently.

[DrJaymz]

You don't need to be concerned with the debug statements, if no debugger is attached they do nothing. With no debugger attached watch out for much faster execution which may change how your program executes if you have not been careful with delays. I had been using I2C and effectively closed it immediately after sending a shut down, in debug this worked well, with no debugger it shut the port down before it had chance to send shut down!

[hanzibal]

With no debugger attached watch out for much faster execution which may change how your program executes if you have not been careful with delays.

Yeah, I've had quite a few problems with programs that won't run (or sometimes won't) without the debugger. I find these problems really hard to track down. As there is no debugger around, I have to do LED-debugging

Actually the Debug.Print do more than "nothing" even when there's no debugger (also in "release") but not enough to slow things down. I don't think the code runs noticeably faster without the debugger.

[Gorf]

Just while we're throwing around "that's how I do it" ideas: I've taken to keeping the blinking LED project on my MRU list, but it's a slightly altered version which just drops out of its loop after ten seconds. Whenever I'm about to start any major reworking of the code, or about to upload a new project to the device, I first "wipe" it by uploading the blinker. It gives a visual reference direct from the device of what program is installed, and because it's inactive after it finishes, I rarely get problems with "preparing to deploy" delays.