Main Site Documentation

Security and deployment


#1

Hi guys

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 ?

Thanks


#2
  1. see loader commands on USBizi manual on the protect command

  2. no you can’t


#3

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 ?


#4
  1. yes
  2. it is up to you on how to handle the file… transfer data…transfer file…use USB…SD card…you have full control. Maybe I didn’t understand the question?
  3. I didn’t understand what you need :frowning:

#5

Point 1 : Done :slight_smile:

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… :slight_smile:


#6

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.

Is this what you need?


#7

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)


#8

Idont know if your using a SD card in your application, but if you do you might store a config file there?


#9

Using SD card is last solution but I’d rather not reach that solution :slight_smile:


#10

You do not need SD. Use EWR…Extended Week Reference. I think this is supported on USBizi.

There is also battery backup RAM that can be used.


#11

But what is the class to be used in order to communicate with the PC?

Which one is it ?


#12

You have to use the USB client CDC (Communication Device Class). This would allow you to communicate with the FEZ using a virtual COM port on the PC.

The eBook explains this in detail.


#13

ok thanks

Only drawback… I need to use SDK 4.1 of the microframework so, use VS2010 (even express)

I hoped but seems not possible to continue using VS2008.

Correct or possible to use VS2008 to achieve this development ?


#14

you need VC# 2010 with NETMF 4.1 firmware


#15

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.


#16

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.


#17

yes, but the dilemma still stands.

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 :slight_smile: It’s the old “feature cut” decision/dilemma, when do you say enough is enough and just ship it?


#18

Brett:

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.


#19

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 :slight_smile:


#20

You’re right brett

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… :wink:

Guess the subject might be closed :slight_smile: