I’ve done an application for my FEZ domino… I want to deploy it… VS2008 do it well for me (thanks MS)…
But I’ve got 2 issues…
1 - In order to prevent bad guys to get back my code (I don’t really care but my boss do), how can I protect my embedded code ?
2 - Inside the code deployed, I have a configuration file used by the application. Is it possible to only deploy an update of the file ? For instance, I could create a small winform application with some GUI to let the user change few configurations and then have a “proceed” button to write the updated configuation on board… Is it possible to do that without including any code inside the embeded application ?
Question 1 : Command “P” will do the job ? right ?
Question 2 : So, If I want to change the configuration file I need to change it on the laptop and then redeploy the whole application ? is that correct ?
Question 3 : Is is possible or is it forecast to be able to access the file system of an embedded system ? (maybe but changing the boot loader)… any issue to that ?
Point 2: My embedded application has a configuration file which contains information about few parameters the user can adjust.
Selling to a customer my product, I’d like to let the customer to change these parameters. I don’t want the customer to use VS nor MFDeploy nor install the MF framework. I’d like to provide the customer a small application in which in could only adjust the configuration parameters and then update the configuration of the product.
Such a feature could be great… and of course, I would like not to give the deployed assembly in the configuration tool to avoid any change done by the user…
Any approach to solve that kind of situation which might seem quite common in the emebeded world…
Enable CDC feature on USB client which will make the device work as a virtual serial device and then you can use your application from a PC to talk to that serial port to send config.
when you say “enable CDC feature” on usb client, you mean use the usb device also used for deployment ? You don’t mean the usb host on the board used to connect any peripheric ?
(because currently, I use the usb host to connect a GPS sparkfun board…
If I can use the usb client (used for programming), I suppose that I have to “do” a piece of code to manage this on the board ? correct ? (it’s not a problem to do so)…
Last question: What class do you use ? How (in few lines if possible)
there’s where your trade-off is. For someone with a commercial product, stability of software platform (dev and firmware) versus the “new feature” that you may now need, are at odds. A change in firmware might introduce new features that would be nice or even critical to the success of the project, but it also resets the bar since you now need to re-test everything.
We usually let users know if we made major changes or not so it is easier to know if you should upgrade or not. Like when we moved from 3.0 to 4.0 we rewrote every single line of code! From 4.0 to 4.0 was very minor fixes here and there and then for the releases that do not involve changes from Microsoft, we have a detailed list of what changed in release notes.
Do I “do nothing” and not get the new feature that might make my life easy or make my product better.
I don’t need to re-test since that’s already done. Cost neutral.
I either don’t get the feature I want or I have to fudge it - lost opportunity, or increased cost.
Do I “upgrade” and get the new feature.
I have to re-test. Increases the cost thru rework and potentially increases time to market.
I get the new feature I want or makes my product better for the consumer. That might increase the number of sales or increase satisfaction with the product.
Which one is the better one for a business to decide?
Too hard for me to tell from the outside - but everyone has a view It’s the old “feature cut” decision/dilemma, when do you say enough is enough and just ship it?
Is it possible to release the product with older software as soon as possible, and then offer an upgrade in a few months? Might be an opportunity to get more revenue.
sure, that can be another combination that might or might not work. You may disillusion cusotmers who are “forced” to pay for a “Feature upgrade” so soon after forking out for the main product (and since we’re talking embedded systems, you may introduce a servicing issue!). You may also get good support from an enthusiastic user base who then want more and more and will pay for it.
At the end of the day I’m sure there’s a planning tool for all this - and since I’m just a bystander to this whole thing I can navel gaze it to death
But, anyway, I will upgrade to NMF 4.1, SDK 4.1 and VS2010… I have “few weeks” before having to deliver the whole product… And, changing configuration by using usb client is really a good thing because I’m already using the USB host for connecting a GPS/GPRS…
