alan smith wrote: > Thanks Bob. Good information. RAMTRON is a little expensive tho, so might have to figure out if the IR based device can be updated differently. > > Off topic...who's cellular modem did you use? > I'd rather not say, as they got into a spot of trouble with the FCC over their design. When I was doing the anklet, the cellular guy was still working out his FCC problems, but a well-known cell service provider offered limited service for extensive testing anyway, with the FCC's blessing. Seemed to work fine. The complete module was only 1.1" x 1.5". made in Taiwan, not China. I am doing another project with bootloader at the moment. This one uses the ethernet port of a touchscreen to access the local PLC. It downloads a PLC program that downloads firmware to my PIC motherboard. When that is complete, the PLC is reloaded with its latest program, then finally the touchscreen itself is updated. It seems to work fine locally, but out on the wilds of the www, it might falter. We'll be testing it. The better way would have the product dialup and update itself, but I don't see a simple solution for this, and I don't want to design an entire portable PC to do just that.... --Bob Axtell. > Bob Axtell wrote: In my designs, the bootloaders are embedded, i.e. the bootloader is part > of the normal serial traffic. > A command is sent from the PC or higher-level software that causes the > unit to commence accepting > packets intended as firmware updates packet. > > But almost none of the PICs contains enough memory to be able to store > all of it; I normally use a RAMTRON > FM24C256 (I2C) or FM25C512 (SPI) to store the packets. There is no > waiting in RAMTRON devices, a very > big advantage. The need for scratch RAM is also so that you can perform > a CRC check on the new firmware in > order to make sure there is no error present. > > Another advantage of using the RAMTRON scratchpad, is that you can > update over several days instead of halting > everything and jamming it immediately. In my case, I was using a > cellular modem, and I needed almost a week to > get all the update packets downloaded because cellular time was expensive. > > The RAMTRON also helps while you are decrypting the encrypted firmware. > Unless you do this, competitors will > steal your design. > > Once the data is absolutely correct inside the RAMTRON, you are ready > for the update. > > --Bob Axtell > > alan smith wrote: > >> So, not having used a bootloader in the past, just trying to determine how it might fit into the future. >> >> Here's the scenerio >> >> Box 1 talks to Box 2 over RS485. Box 2 is remote, hidden away and not easily accessed. So the thought is, run a bootloader in box 2, that the PIC in box 1 can update its firmware. This of course, requires that either a external serial memory is attached to the PIC in box one that just stores the program as I am quite sure there isnt enough memory internally to store both. Lets just assume there isnt because as the features change, program could get larger so better to design for that to begin with. >> >> So, PIC1 just streams out from the serial memory up to PIC2, assuming that it sends "something" to enable the bootloader in PIC2? I guess that "something" is usually whats running on the PC that is uploading the program but no reason the PIC can't initiate the bootloading? >> >> Now for a bit of a kicker. There is a third device, that talks to box2, that also contains a PIC but has a IR data link. Sure the data rate might be slow, but again...its a wireless link instead of hard wired, no reason it can't run a bootloader as well and do a firmware update over this link as well? >> >> Welcome to opinions on why this wouldnt work >> >> >> --------------------------------- >> Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. >> >> > > -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist