Non IDE propeller chip programmer!
Is there or will there be a way to program the Propeller chip from a non IDE software? Do you have information on the type of protocol or bitstream info to program the device over the serial or USB port. This device will be used for a commercial application and we want to send a customer a firmware upgrade and to do that we would like to send a file only (no hardware). We have the software/hardware expertise to do this if we can just get as much information as possible on how this process works. We need to get our product launched very soon and we need the horsepower of this micro to complete our product. *Please help us*
Thanks,
Eric
Comments
There are other posts that talk about how to load a propeller chip (examples in Delphi, and one in spin). Using the python, delphi, and spin examples you could probably whip up a custom one to work in your application. Use search.parallax.com/ to search for these examples.
Harrison
Then the software updates are just shipping a new card, and of course if something goes wrong they can always put in the
original SD card. You don't even need to use the FAT16 routines if you wanted; you can just use it as a block device, which
requires only a tiny bit of code in either assembly or Spin.
Now that sounds interesting [noparse]:)[/noparse] I know you've been doing excellent work with the SD routines, but how would we get a PChip to boot from one?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
Thanks,
Eric
Thanks,
Eric
If the SD card formatting is under your control, and you can format it with 32K clusters (should be
straightforward), and you want to use FAT16, then you can pretty easily use the fsrw code I posted
(http://tomas.rokicki.com/fat16work) to locate the starting block of any file, and then pass that
starting address to a cog routine that will load that contiguous 32K of data directly into main memory.
(Careful here, though; you need to make sure the var space is zeroed. This means the file should
either be a full 32K "EEPROM" file and not a "binary" file [noparse][[/noparse]the IDE can create either or both], or you
will need to add code to interpret the first part of the file to figure out how much memory to clear,
since it's guaranteed that the var space is clear at startup).
If you want to dispense with a filesystem altogether, you can just use an SD card like an
EEPROM, and load 32K of data from any offset you care to. (In this case, a cheap 512MB card
can hold about 16K different images!)
Then, to actually "start" that image, you'd have to look at Mike Green's OS code on how to do this.
(Although you want to make sure to kill off all cogs except the one doing the rebooting.)
If you want to support general FAT16 filesystems (that might not have a 32K cluster size) it's a
tiny bit more complicated, because you need to get the block offsets of all of the blocks in the
file, and the cluster size might be as small as 512 bytes and not contiguous. But even here it's
not too bad; just get the requisite 256 block pointers, copy them into cog memory and load them
sequentially.
If you're concerned about depending on an SD card (and the contacts in the slot, etc. etc.) you
can instead make the boot code simply check for an SD card, and if one is there, verify and copy
the data on the card to the normal boot EEPROM. This whole process should be relatively quick.
In this case, the device can operate without an SD card, but you can still ship out updates on the
SD card.
So what do you think of these ideas? If you let me know which sound right to you (file system or
not, depend on 32K cluster size or not, boot from SD or just flash the EEPROM from SD) I think
I'd enjoy mocking things up for you.
1- Yes.
2- Yes, "Use search.parallax.com/ to search for these examples.
Harrison"
There is no nice, ready to go solution for you, but there are many bits and pieces. The Python downloader is the best software solution. If you want something in Visual Basic or C++, you'll have to translate either the Python or Delphi stuff or Chip's sort of flowchart description to one of those languages yourself. Several of us are working on various ways to get information from either an SD card or USB flash drive into a Propeller, but these are not finished.
Mike