Programming a PChip using other than the IDE.. Possible?
sharpie
Posts: 150
Is it possible to push 'EEPROM', or 'Binary' files that have been saved via the 'View Info' window in the IDE to the PChip from a VB app?· If I build a device and hand it over to users, and wish to provide 'firmware updates' on occasion without my intervention?· For example, they have a windows (VB)app that talks to the device (which has a ftdi chip setup just like the demo board) and I want them to be able to push a button to update the 'firmware' on the propeller in the device....· The app would go out and grab the latest 'firmware' from a server and push it out to the PChip, reprogramming it's eeprom·with the updated code.
Am I dreaming?· I'm sure it's probably not easy, but if it's possible I am interested to say the least....
Am I dreaming?· I'm sure it's probably not easy, but if it's possible I am interested to say the least....
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
#1) YOUR spin program must have a module that will permit it to DL (from what ever means you design), and store the code into eeprom, which means your spin app must:
....have a means for knowing when to go into 'update mode'.
....have the I2C object included in it's source, to talk to the eeprom (that eats some of the 32k ram...)
....have the Serial object included in it's source to listen to the incomming data stream (that eats more of the 32k ram...)
#2) YOUR VB app must simulate what the IDE does when it DL's to the propeller.
I don't know if Parallax would release the "how the IDE DL's into the Propeller's EEPROM" RFI, one can only ask.
And Just an FYI: Only YOUR spin code can be updated... not the acutal propeller firmware.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller + Hardware - extra bits for the bit bucket =· 1 Coffeeless KaosKidd
·
seems doable with only the extra cost of a EEprom and a spdt switch... less than $5
dan
Oops , meant DPDT so you could swap pin one of the EEproms from high to low and viceversa
Post Edited (Sawmiller) : 8/16/2006 2:59:44 PM GMT
however sharpie was looking for a way to update over the internet, and the cost of sending a stache or prop with every finished project would be higher than just including a extra EEprom and some code in that eprom to grab a file from a computer ( assuming the file was d/led in the first place)
dan
Anyone care to have a go? -- Not sure I've got enough brain cells for the task
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
Chip Gracey
Parallax, Inc.
You can put me down for a copy of code on the subject.
Please comment a little as I've not dealt with delphi.(mainly where it differs from VB.)
[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller + Hardware - extra bits for the bit bucket =· 1 Coffeeless KaosKidd
·
Kaos Kidd: Very convenient since I have all those objects included in my project already! (I was using the word 'firmware' in reference to my code=) )
So, Chip.. .Does this mean that we'd use the 'Propeller Loader.spin' in conjunction with the Delphi code to update the eeprom? Also, probably should wait to see the code but I'm anxious..... Is there a way to specify how much of the eeprom it overwrites, so it can leave a certain address range untouched? (for example, datalogging writing to the eeprom and wanting to keep that data after the 'update' is complete..) If not, no worries but doesn't hurt to ask..
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller + Hardware - extra bits for the bit bucket =· 1 Coffeeless KaosKidd
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Jeff Martin
· Sr. Software Engineer
· Parallax, Inc.
I'll let the forum know when I have it. It could be something that any program or batch file could call, and pass it a file name of the image to load.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Jeff Martin
· Sr. Software Engineer
· Parallax, Inc.
what if someone were to write the PC app to use I2C protocall, and you provide connection (ie 3.3 volt data conversion and ground) to the eeprom?
Then you can do what ever you like, and it should work just fine... right???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller + Hardware - extra bits for the bit bucket =· 1 Coffeeless KaosKidd
·
I'll try and wait patiently.... try...
See www.turboexplorer.com/ for more info.
Jeff, any chance of that little utility providing any feeback for the calling application? As for progress, success, etc..? I'd love to be able to show a progress bar during the process. Maybe an activeX component? too much to ask? I'll stop...
Oooh, more free programming software. I got the free Visual Studio 2005 last month from Microsoft. I will definitely check this out. Thanks for the link.
I was thinking of having a memory/file management program running on a PC or other platform, that communicates with the Pchip when it starts(the Pchip powers on) and loads operating software into the Pchip. This puts the Pchip device into a slave like mode, with all the management software running in ram. The computer end of the software is the GUI, status display and communicator, it operates in a master like mode. If a file needs to be added to the Pchip device the "master program"configures the data into Pchip form then requests the Pchip("slave") to download and store it.
... this is theory now but my Prop just arived!
I jumped for joy and now must get back to my point.
The device (a book reader) I am designing will have read only access to its memory(except where local/private data is generated by the Pchip). The reader will only be able to display, via an internal or external mem card, the selected page. In order for data to be added or removed from the internal memory another computer is used in a master(PC)/ slave(Pchip) relationship.
But central to this is the ability to leverage the power up sequence like the IDE does, by presenting a comms interface on P30-31 and dumping the Pchip half of the file/memory management software into ram. While connected the computer GUI is "driving" the Pchip device and when done blocks the comms interface while restarting the Pchip from EEprom into its limited read only display mode.
So could you use a similar system to froce the update through the Pchip power on sequence. like:
Run the update("master") program on a computer. connect the Pchip(via USB?), power up the Pchip.
Finds comms on P30 and P31.
Load the Pchip with a version check, inform the "master" of the current version and wait, if a new version is available the update program sends it from the PC and writes it to EEprom.
Block the comms(PC) and restart the Pchip.
I'm looking at this as a way to limit user interaction while allowing(without having to include the code on the Pchip) greater functionality in concert with another computer.
For what it's worth.
Frans...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Read a book, under a lamp and think what it took to get here.
Here is the link: www.marcocantu.com
They are enough to help you translate Delphi code, or begin developing with Delphi.
The Pascal one in particular should also help with understanding Spin, since some of the syntax is similar.
Any idea on timescale? Yesterday would be good
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
to quote from the program
''This object drives the other Propeller's RESn line, so it is recommended that
''the other Propeller's BOEn pin be tied high and that its RESn pin be pulled
''to VSS with a 1M resistor to keep it on ice until showtime.
neither of these lines are in this state in the demo or the prop or the homemade pic off the forums...
normally the boen is tied low and resn isnt tied
is it easier to change the way the loader works, or put a slide switch in to change the 2 pins ?
dan
The idea here is that the Propeller which does the loading of the other Propeller will dictate RESn in case of a brownout, just to give them one mind about power status. When the first Propeller's brownout trips, that chip will go into reset, causing its I/Os to float. It will cease driving the secondary Propeller's RESn high at that time, and the attached 1M resistor will pull it low. That way, both chips respond to the same brownout level. As long as power's good and the secondary Propeller has been loaded, it will keep running. Whenever it gets reset, it needs to be reloaded from the first again. Well, this assumes that there is no EEPROM attached to the secondary Propeller, as the program must reside in the first Propeller's EEPROM, anyway.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
are you saying that the proploader program will act like F10 and not like F11 ?
dan
Is there any chance that loader could be used with any chip using a uart?
(would like to use a third party chip to load the prop and eeprom and free up the pins on the prop for another app!)
It's not clear just what you want. Any chip that's fast enough to produce a continuous stream of asynchronous output and has enough memory to hold a program to be downloaded should work for downloading to a Propeller. Downloading to RAM is much slower than booting from EEPROM although you have to do this only once after power up. It would be really easy to add an I2C I/O expander like the MCP23008 or PCF9554 or PCF8574 none of which require any extra parts.
Alternatively, you could use two quad transmission gates like the MC14016 to disconnect the four pins (28-31) from your external circuitry for a second or two (using a 555 to stretch the Propeller's reset signal) and connect them to the serial line and EEPROM. That way you could still use the Propeller's boot loader, yet really have the 4 pins to use for external control.
Mike
I finnally got my propeller in yesterday and I am eager to start milling a board for it. What I want to do is download the code from the IDE into a dsp33 from uCHIP and have the Prop read in the program from the dsp's I2C line as if it were eeprom. Then reprogram pins 32 - 29 for control of a 16 bit bus between the two.
Unless someone can confirm that this has worked before I plan to use jumpers in the four lines to configure the switch between my idea and the prop demo schematic version and then just use an eight-bit bus instead.
What I am afraid of is: Does the IDE have to confirm there is a propeller on the serial line before it will download? ( as I may not be able to fool the IDE into believing a 16 bit dsp Processor is a bonified propeller.
Yes, the IDE makes the device on the other end of the serial line jump through some hoops before it will actually download. The code that Chip posted gives the details, but, basically, the PC sends some calibration information, then a pseudo-random bit sequence which the Propeller has to acknowledge/echo, then the Propeller continues the pseudo-random bit sequence for a while, and finally provides its version number, all within about 50ms. The Baud required is 115200. I imagine the dsp33 can do this. I've been trying to get the Propeller to download from the IDE using some other I/O pins and haven't been able to get it to work, but I'm also using a Mac to emulate a PC to run the Propeller Tool and timing on the PC end is marginal.
Mike