1 2 Previous Next 24 Replies Latest reply: Jan 11, 2013 5:50 AM by mcb1 Go to original post RSS
  • 15. Re: Self-Destructing arduino code
    sonuame Level 3

    See...I told you...EEPROM way is the best...!!

    dont bother abt write cycles, you just have to read the values continously to keep ur sketch active.

  • 16. Re: Self-Destructing arduino code
    dirtdiver Level 7

    yes in terms of number of writes available i will be OK, and as far as the legal side goes im not selling this im getting involved in a partnership, and the club is not mine so whats stopping the guy from saing thats his, i have no way of proving that i made the simulator and like i said i can gain leverage when i simply render the teensy useles. (I am also thinking about patenting the simulator but im not sure how to do that or what will the cost or time be like)(The other possibility is a contract which i will look into)

     

    Anyway thanks for the help,i will keep you posted on my progress!

  • 17. Re: Self-Destructing arduino code
    000Plasma000 Level 4

    Don't patent it!

     

    I tell you, it's a waste of time, money and effort. You need to pay thousands of dollars, and here's the worst part: you have to publish a detailed description of your product and how it works! You're just making it a hundred times easier for some el-cheapo manufacturer to copy it! They won't care if you have a patent. If you do decide to sue someone over copying it, then that's going to set you back quite a bit for a lawyer! There's no way, even if you win, that you'll get that much money back from the patent.

     

    If you decide to sell it (perhaps on a large scale) then there are precautions you can take to stop people from copying it. For example, you could get a custom PCB built for it, and sandpaper off all the markings on the ICs. If and when you decide to go big, then maybe a patent might be feasable. Also, if you don't really care about the money, and just want to get recognised, a patent might be a good idea, even now. Just know that you'll be paying a LOT of money for it. Think of how many goodies you can get on this website for $5000!

     

    ---

     

    Also, @Sunil, the EEPROM method may not necessarily be the best way. In fact, there may not be a 'best' way at all. It's one way of doing things, and it seems feasable. It all depends on what the kill switch is for, how much effort you are willing to go to write the code, how good you are at coding, your time constraints, etc, etc, etc. This kill switch idea is good, but I can see it causing some disputes. A dedicated self destruct button will tick off the club owner much more than a simple discreet reset switch (which by the way, is not analogue as you mentioned before - analogue refers to a range of voltages in this case, the reset switch still uses digital logic), and you can still use the switch for leverage. Just tell the guy you need to take it for 'servicing' and secretly flip the switch while pretending to calibrate stuff, and give him a long technincal explanation as to why it went bust, like "the internal temperature of the dual H-bridge stepper driver rose too far beyond the nominal". He won't know you designed it for leverage (which I'm sure will make him mad and ruin the partnership), but he will know that only you can fix it, which gives you the leverage. Also it requires no extra coding. In addition to this, constantly checking the EEPROM might be quite taxing to the microcontroller, especially since it's doing a LOT of other work - this simulator is pretty complex! You might find that it decreases performance. This might be in the form of jittery servos for example - even with simple programs, if the MCU is checking constantly for, say, a timer value, then the servo just freaks out and goes all over the place! You could optimise this out using interrupts and all that but that just adds to the complexity of your program!

     

    Again, this is also just one way of doing things. It may or may not be better than the EEPROM method, but it's up to dirtdriver to decide

  • 18. Re: Self-Destructing arduino code
    mcb1 Level 15

    Rahul

    Someone in the Arduino.cc forums did a self destruct, by writing and then reading the address.

     

    The 10/100k write is the MINIMUM the manufacturer guarantees it will work for.

     

    I think (hazy memory) it was more like 1m write cycles he got.

     

     

    Anyway as everyone has posted, it only needs to be written once.

     

    dirtdiver

    You can run the button check routine as an interrupt, or whenever you read other inputs.

    This would clear the EEPROM (or write to it) and on next powerup, when it checks.......

     

    To make it look genuine, after the 'self destruct', you could always make it do a loop that looked like it 'booted' up then died and repeated.

     

    "Genuine failure mate, probably something inside the micro .....I can fix it, but btw about that account..."

     

    I have been known to remove the chip identity by sanding it off, when we didn't want it reverse engineered.

    Black spray paint, or encasement in rubber solution or epoxy (with glass) is also frustrating.

     

    Mark

  • 19. Re: Self-Destructing arduino code
    sonuame Level 3

    @Rahul,,

    yeah i am agreed to you , I just told that Reset pin is too much a easy way to stop execution of the microcontroller for that complex machine.

     

    sure continously reading the EEPROM values sometimes may delay in response and surely it will impact the servo one day theoretically...but so far now I have not seen such a case yet..May be i have to do some more EEPROM stress analysis.

     

    What if we mount a small RTC IC (DS1307) and read the EEPROM values after a specefic period of time say once in 2 days or 4 days etc...coz that will surely give the chip some time to relax. And if the value is not there after 2 days...Simulater will shutoff...!! until unless the value is not saved in it again.

     

    DS1307 can last upto 5yrs approx with a single coin cell and we can detect from the Arduino or any other Microcontroller wether RTC is running or not, just incase if somebody plugs out the cell from it and make our program much stable and secured with it...

  • 20. Re: Self-Destructing arduino code
    dirtdiver Level 7

    Yeah, thats what i heard about the patenting too, so its out of the game,

    also im not worried about reverse engineering couse all they are going to see is the teensy the code in it cant be extracted as far as I know (it can but it will be all messed up and not full- it will be pretty useles)

    I have a friend lawyer, i will talkmto him about a shor contract declaring that i have rights over the simulator or something similar i dont know yet .

    Im not a good programer,as you can see from the simulator i dont have that kind of money to fool around with , i dont have much time,I will try the EEPROM (at least for the educational purpose of it , but if it slows down the program, then i wont use it)

  • 21. Re: Self-Destructing arduino code
    ntewinkel Level 14

    I really like Sunil's idea of it only checking after a few days! Much less obvious that way. You might also make it use a jumper on pins instead of a button, to prevent accidental presses.

     

    You could probably just use millis() to check, as it rolls over after 50 days, which gives plenty of time: http://arduino.cc/en/Reference/millis

    So you could check at startup, and every time millis() is divisible by, say, 200,000 (2.3 days).

     

    Kind of like this:

     

    void setup() {

           if (EEPROM.read(0) == 42) {

                selfDestructLoop();

           }

    }

     

    void loop() {

     

         if (millis() % 200000ul == 0) {  // test with a smaller number. I think you need the "ul" to indicate "unsigned long" to allow for the big number.

              if (EEPROM.read(0) == 42) {

                   selfDestructLoop();

              }

         }

     

         // do regular work

     

         if (selfDestructButtonWasPressed()) {

              EEPROM.write(0, 42);

         }

     

    }

     

    void selfDestructLoop() {

         // blink the warning light.

    }

  • 22. Re: Self-Destructing arduino code
    sonuame Level 3

    @Nico,,

    I guess, millis() gets reset once the sim is shutdown, hw exactly we can track the number of days passed

     

    For me RTC was the good choice for the timing purpose..its small, cheap and very much reliable

    I hve made a number of RTCs at home.

     

    @dirtdriver

    So you started the work dude....!!!

  • 23. Re: Self-Destructing arduino code
    ntewinkel Level 14

    Hi Sunil,

     

    I agree, millis() gets reset on startup. My thought was that if the sim is running and the button was pressed, it would run for a few days and then shut down. If it is restarted anytime sooner after the button was pressed, it would fail immediately and it would look like there was a startup failure of some sort.

     

    I do like your RTC idea too - they're not too pricey either.

  • 24. Re: Self-Destructing arduino code
    mcb1 Level 15

    If I might be bold enough to suggest the following :-

     

    Have a number in the EEPROM.

    Also have the number of starts in EEPROM.

    Read both at Power-up/Arduino reset, and add one to starts, re-writing it back to EEPROM.

    You get more than 10k writes, which is 27 years at once a day. (minimum)

     

    If the button is pressed, clear the number OR replace it with the number of starts.

    At next power-up when you read it, either it goes into 'fail' mode, or does x more starts before going into 'fail' mode.

     

    No need for extra hardware.

     

     

    Mark

1 2 Previous Next