>>>> skill required to get this done
^
^
^
^ (Note the big gap)
^
^
^
^
<<<<< me

The encryption idea sounds cool, but I think it's a bit (OK, WAY) over my head at this point.
Trying to get the SD card bootloader off the ground will be daunting enough. Off to read some more.....

 

That is why I offered to help you; you seem like a good fellow with a boatload of problems, not to mention time pressure to produce.

__________________
We never have time to do it right; but we always have time to do it over.

 

Much appreciated.

As you probably pieced together, my current PCB layout (still in CAD) is built around a CUBLOC controller ==> Comfile Technology Inc.

The various portions of the hardware and the code have been prototyped and worked out but the choice of the CUBLOC keeps nagging at me. I like the product and have some experience with it but keep coming back to 3 roadblocks;
1.- No ability to offer firmware upgrades
2.- If I want to outsource the software engineering at some point down the road as this product develops, I would need a mainstream controller.
3.- Unknown reliability of supply for the CUBLOC part.

So, I'm ditching the CUBLOC and jumping into the PIC world with both feet. I've read a lot and think I get the gist of how things are done. I have a programmer and PIC due in any day now to proto with. I'll try some stuff out and be back with the inevitable questions.

Thanks again

 

I assumed that you were going to charge for the future upgrade and was trying to point out that an encrypted file can be passed from Paul the plumber to Bob the builder very easily. You could find that a company with 50 employees would buy 1 upgrade and use it 50 times and then post it on the internet. Encryption without serialization will not stop this.

You state you are using an RTC. If you use a Dallas one wire device then these have a serial number built in and could kill two birds with one stone.

Mike.

 

The equipment talks to a server. The biggest reason for an update would be in the event that we have to make a change to the location of or format of the server. Not really intended as a revenue stream. In fact, having a customer able to update all their units with the same chip would be a bonus.

Now you have me thinking... perhaps a hybrid approach would make sense. There could be a "serial number required" flag in the firmware file, where some updates (like a server change) would work on any unit, but a billable new feature would only work on a given target unit. I think I like that.

I am using this RTC ==> ISL12026*Real Time Clock/Calendar with I²C Bus™ and EEPROM It has on board EEPROM for S/N and other configuration data

Thanks for the ideas. good stuff.

 

If I understand correctly, you have a design with a PC Board currently in layout. Changing horses at this point would involve a severe schedule impact as you are no doubt aware. Unless you have uncovered a showstopper in the CUBLOC controller, I would advise you to go for the best result possible rather than the best possible result.

I can also recommend the AVR line form Atmel. They have good support and there are a range of development tools both free and commercial. The in system and self programming capabilities are excellent. Here is a link to the 8-bit line:
Atmel Products -Microcontrollers - AVR® 8-Bit RISC

Good hunting

__________________
We never have time to do it right; but we always have time to do it over.

 

The design is sitting in a ARES file on my PC. It hasn't gone to the PCB house yet. The only schedule demons I face are self imposed, I have no real deadline. I'd rather get it right than rush it.