I am having some success with gadgeteer and am now using the extender module on
socket #9 to output analog to a voltmeter. My program uses a button to toggle 0 v to 3.3 v.
I was successful in running under debug, then I deployed a release build
which seems to have downloaded my application to the firmware as now it runs
by itself (ie unplug the usb , power off, back on and it runs.)
This is all good, but now I am having difficulty going back to run it under debug!
Now, I wanted to change the program to use the GT timer to periodically step up the voltage till 3.3 then go back down. I think I know how to use the timer ok and have it
send the event but -
The problem is that I don’t really understand how the deploying/erasing/writing firmware
works on this platform.
From vstudio, I rebuilt the solution, cleaned it, deployed it, but nothing puts me back where I can debug it.
It seems as if it is still just running the previous program I had deployed. I think probably
if I start a new project, this may work, but I don’t want to start another project, I just want to make some changes, debug and redeploy (preferably just from VStudio).
I looked at FEZConfig too, but there is no documentation I can see that explains how to use the Deployment(Advanced) feature. For example, there is a button to erase application but if I press it, it asks if I’m sure I want to delete the managed application (what is that??). I just want to erase the firmware (I think) and go back to debugging my new changes, then redeploy my changes.
Can someone explain how I should be doing this ?
Thanks!
If I exit vstudioExpress and then come back in and reload the project, I am back
in business (able to debug again).
Seems this vstudio ide is a little hokey to me as I’m used to another ide for doing embedded systems which lets me erase the firmware and download and do whatever.
If anyone knows a way to control the embedded/firmware from within vstudio, plz let me
know.
Otherwise, it seems I’ve answered my own question!
So probably the most likely cause of this “behaviour” is somewhat because of the app you’ve got deployed, and because of your history of build --> deploy in your previous experience you may not realise what’s going on.
Let me point out one thing you do need to perhaps think differently about - your app, once you deploy it in either debug or release mode, will run autonomously if you take the board off the PC and just power it. This isn’t a function of release mode - in fact I personally never use release mode, and others may like to comment on whether there’s things you improve by using release or not.
VS can talk to a running mainboard, without problem, whether it’s running an app in debug or release mode. There are some cases where the debugging thread on the mainboard is unable to get processing time to respond to the PC, and often this is because your program forces a “tight loop” with no time given to the scheduler - if you have a while(true) type loop as your main “application” processing loop, simply adding thread.sleep(1) is usually sufficient to relinquish execution and the debug thread can get a look in. Another approach is to simply sleep the app on startup or wait for an arbitrary event (button press or button release) before you start the main thread, holding it in a thread.sleep() loop until you do, and then to restart your app by resetting the board.
Often times the simplest way to “recover” a board in this situation is to just reset the board when you attempt to deploy the updated code as I mention above, this often also works in the tight loop scenario. In the “worst” case scenario you might just have to erase your app from the device, or redeploy the firmware, using MFDeploy or FezConfig.
So your situation just smells weird. The workflow you want is more than possible, its the expected behaviour. Can you tell us if there’s anything special about your app or about the way it works, based on the above background?
Another “layer” I didn’t explain that I think is worth doing so.
The Netmf Firmware is multi-layered. You have a bootloader that handles firmware updates. You have a firmware that provides the netmf foundation that your app will leverage. And then you have your app (the “managed” code). You can update the first two items but you can’t (easily * ) create your own firmware and deploy it. Your application sits on top of that, so you can, with FezConfig or MFDeploy, erase just your app safely, and then redeploy an update to it.
Simplistically I’ve answered no. It’s a more/very advanced task, but yes, it is possible to create a new firmware if you really wanted to. There is no way to start from a “known” source for the Spider because that is GHI Proprietary “premium” product, but for the Cerb family for example the source is “open” and can be added to, and the community has done so.
I sometimes have a similar issue. Have a look at the Output window during deploy. If it says incrementally deploying… Then see whats next. If it says noting to deploy then there is a Problem in VS I think. Havent solved this. I always use MFDeply to erase deployment. Then deploy With VS again
Brett, from your first post - you asked the question if there is anything special about the app or the way it works based on improper use of while loops, thread sleep, etc.
No, I am only running a very simple app which in the programStarted routine sets up
an analog output and a timer, sets up timer tick event handler and starts the timer.
the tick event handler function just has some code to either bump up or bump down the
analog setting (goes from 0 to 3.3 by .5 v). But no while loops or sleep, etc are in my code.
The program runs fine - now that I reopened the project - thanks for all the info, I will study
it and try to understand what you’ve posted.
Reinhard, thanks for the info, I’ll try to pay more attention to the output window…