Programming without Propeller Tool
T Chap
Posts: 4,198
I need a very slick solution to do remote updates. Is this idea below possible?
A standalone executable Mac or PC application containing a new Propeller software update(in binary?) is emailed to a client, or DL'd from a site. The client plugs a USB cable into the Propeller PCB from their computer, runs the application and the update data is sent to a 2nd EEPROM used as temporary storage. Once received, the file is compared to the original on the computer, if no errors, the Propeller transfers the update from the standby EEPROM to the boot EEPROM and does a reboot. What are the potential problems? If there is a power out while the transfer from Temp to Boot EEPROM happens, the worst case is either a new boot EEPROM has to be sent out or either the code has to be sent along with the Propeller tool.
Another idea regarding EEPROM updates: Can the original boot EEPROM stay in tact, but after boot, it reboots and loads the Temp EEPROM to load the main program? An example, there is a latch that only a power off can reset. This latch can be configured with some logic to reverse the Boot EEPROM and the Temp EEPROM addresses. On power up, the latch is off, the main boot-up program runs, toggling the latch ON followed by a reboot. The temp EEPROM is loaded next with the real program, since the addresses have been swapped by the latch. Anytime a new program needs to installed, simply write over the Temp and reboot.
Post Edited (originator) : 3/8/2007 10:25:10 AM GMT
A standalone executable Mac or PC application containing a new Propeller software update(in binary?) is emailed to a client, or DL'd from a site. The client plugs a USB cable into the Propeller PCB from their computer, runs the application and the update data is sent to a 2nd EEPROM used as temporary storage. Once received, the file is compared to the original on the computer, if no errors, the Propeller transfers the update from the standby EEPROM to the boot EEPROM and does a reboot. What are the potential problems? If there is a power out while the transfer from Temp to Boot EEPROM happens, the worst case is either a new boot EEPROM has to be sent out or either the code has to be sent along with the Propeller tool.
Another idea regarding EEPROM updates: Can the original boot EEPROM stay in tact, but after boot, it reboots and loads the Temp EEPROM to load the main program? An example, there is a latch that only a power off can reset. This latch can be configured with some logic to reverse the Boot EEPROM and the Temp EEPROM addresses. On power up, the latch is off, the main boot-up program runs, toggling the latch ON followed by a reboot. The temp EEPROM is loaded next with the real program, since the addresses have been swapped by the latch. Anytime a new program needs to installed, simply write over the Temp and reboot.
Post Edited (originator) : 3/8/2007 10:25:10 AM GMT
Comments
The current FemtoBasic has the ability to load and execute a Spin program from either an SD card or a 32K page of EEPROM. The routines that do this are designed to be included with other applications. The easiest way to do remote updates would be to use an SD card, download the ".binary" file for the program to the Mac/PC and copy it to an SD card, then plug the SD card into your Propeller based system. Your Propeller system, when turned on, checks for the presence of an SD card, then looks for a file with a specific name. If present, it runs it.
If you actually want to update the boot EEPROM, you could have a switch or jumper that, when on, is sensed by your program and, rather than running the program with the specific name from the SD card, copies the program into the boot EEPROM, then reboots.
All this is doable with current software. You could even prototype it using the current FemtoBasic since it has a command to copy an SD card file to EEPROM and, as with all its commands, this can be embedded in a program.
---
Addendum: In my enthusiasm, I forgot that the OPEN statement in FemtoBasic aborts execution if the file (or SD card) is not present. It's very easy to change if you're still interested in prototyping this concept with FemtoBasic.
Post Edited (Mike Green) : 3/8/2007 3:34:24 PM GMT
The stamp editor can create an executable program that loads the stamp with an embedded (checksummed?) binary, complete with a configurable banner which your oems can customize for their purpose. This ability is sadly lacking for the propeller.
Please, oh please can we have something similar for the propeller tool?
When glancing at the Ft232BL manual, I noticed that it has the capacity to operate an EEPROM, but then allow other hardware to access the EEPROM as well. I don't think it is I2c, but is it some protool that could be accessed by the Prop?
Would it not be possible to send the binary data in strings to the Propeller and have the Prop just write it to the Temp EEPROM? Or by some mechanical or electronic swithc, send the binary to the SD card mounted on the Prop board via the Props USB programming port, then have the Femto boot from it?
Post Edited (originator) : 3/8/2007 4:13:29 PM GMT
Yes, you could certainly have your own download protocol. Someone had posted a downloader for bitmap files that was based on the Kermit protocol. You could easily modify that and write to the EEPROM. If you had a 64K or larger EEPROM, you could always write this to the 2nd 32K page of the EEPROM and load directly from there while keeping the boot EEPROM unchanged until you're ready to change it. There are versions of Kermit available for many different platforms (Windows, Mac, etc.) so you wouldn't have to write your own desktop program, just document how to do the download using Kermit.
I understand that due to timing restrictions the Propellers boot code does not really use the RS232 start stop protocol, because for that to work the Propeller needs to know i'ts own working frequency to a 3% accuracy.
Because it will boot using the internal R/C generator the clock speed is not known to the boot code nearly accuare enough.
It would perhaps be possible to partly solve this with a trick, by sending an "AT" like byte sequence and timing the length of the first bitlenghth after the startbit (just like an old Hayes compatible modem), but I'm not sure this would always work reliable.
I think I understand that Parallax has used another trick, something that uses a whole byte for one transmitted bit.
I can see how that would be possible by sending a sequence of either '0011111' or '0000011' seven bit per character "bytes" no parity, one stop bit, so that each bit is sent by either a sequence of 3 zero bits and six one bits (including start and stop bits), or a sequence of 6 zero bits and 3 one bits.
The propeller could reliable synchonise to such a data stream without having to know it's own clock speed.
After that, the stream if these data bits could be assembled to bytes, simply by using the normal start/stop bit RS232 protocol.
But even assuming this is exacly the protocol used, then we still do not know how information is embedded, and for example how the propellor knows whether to upload the 32K received data to the EEPROM or not.
If the complete protocol is known other software can be used to upload data to the prop, for example directly from a C-compiler, of from a Linux or Mac system.
Or in this case from a stand alone upload application.
Mahjongg
Where do I start to learn the Femto stuff?
I assume you are suggesting that a USB type SD card writer/reader is attached to a computer, to which the update file is writen. I use those Flash cards from the cameras alot, just a reader attached to USB, drag and drop files.
Any possiblity the Prop could read the flash card off the USB dongle conneted to the board, or is it mandatory to place the SD card into the reader mounted on the controller board?
Here's a link for a loader written in Python: http://forums.parallax.com/showthread.php?p=622354.
originator,
The USB devices used for programming (USB2SER, PropClip, PropPlub, etc.) are all USB-serial adapters and are USB slaves. You can only attach them to a USB host (usually a PC).
I was suggesting that a standard USB SD card writer/reader be used on the PC side. You can even get some SD cards with a built-in USB connector that appears when the SD card connector is "folded back".
You don't need a reader mounted on the controller board, just an SD card socket and a couple of pull-up resistors. The setup needs 4 I/O pins on the Propeller. Download Tomas Rokicki's SD card FAT driver from the Parallax Object Exchange. The comments in the source program gives the details. You could mount the SD card socket several inches from the Propeller ... I've used a 12" cable with SparkFun's breakout board.
The current FemtoBasic thread is here: http://forums.parallax.com/showthread.php?p=634092
just pops out the existing one and puts in the new one (and they can always go back). The EEPROM then just contains
code to boot from the SD card. Of course, here you need to send out something physical, but it is small and cheap.
The key thing though is it is foolproof; the client has little chance to mess it up.
Thanks for pointing out that Kermit had allready been implemented. I used to use kermit, and I found it way more flexable and reliable than xmodel.
Do you happen to have the location of that thread. The *wonderful* search button couldn't find it.
Originator,
If you use a microSD, you could have a technician in the field download the .binary file with a cell phone, right to the microSD card.
Of course, microSD, are not as populas right now.
I use a microSD card with FemtoBasic with a breakout adapter from SparkFun.com and it works great! (Thanks rokicki and mike)
Just my .02.
Doug
The info in the object suggests there are 6 pins to pull up. In Eagle this is what I come up with for SD. They are show in the same order.
Sparkfun version too here
www.sparkfun.com/commerce/product_info.php?products_id=204
Post Edited (originator) : 3/8/2007 5:52:56 PM GMT
Would it be possible to use the counters in NCO mode to generate bit timing? If the host sent a character like an @, then you could measure the low time. This is a nice character because it's 0x40 or %01000000, and can be typed in a plain old terminal program. If you assume 8N1 then you'll see the start bit + 6 zero data bits, then a 1 data bit, 0 data bit, and the stop bit. If you measure the duration of the first group of consecutive 0 data bits then you have 7*bit timing. If you use a byte like 0x80 instead then you have 8*bit timing which may be nicer to deal with and I'll assume that in the following.
Now let's assume that we're talking about a hardware design instead of just the propeller since I may botch that discussion. If you assume a 16-bit NCO and a 16x baud clock, then if you knew your desired baud rate and the actual reference clock frequency you would program the NCO increment with: NCO increment = 2^16 [noparse][[/noparse]16-bit NCO] * 2^4 [noparse][[/noparse]16X baud clock] * baudrate [noparse][[/noparse]bits/s]/Frefclk [noparse][[/noparse]cycles/sec].
Now if we measured the synchronization character with custom hardware we would have: Measured width = Frefclk [noparse][[/noparse]cycles/s] * SYNC character width [noparse][[/noparse]bits] / baud rate [noparse][[/noparse]bits/s]
Let's assume a sync character with 8 consecutive 0 bits (0x80 byte) and solve for the NCO increment: NCO increment = 0x800000/ Measured width
After this you could look for additional sync characters to verify that you've established the correct baud rate, and then echo something back to the host to let it know.
Would such a scheme be useful on a propeller for anybody? Connect to a host with an arbitrary baud rate, and sync up despite having an unknown reference frequency? I don't know if the hardware is suitable, and with what accuracy you would be able to measure the syncronization character.
ah, so it seems to encode 32 bit words into short and long pulses, with the following Phyton code:
def encodeLong(value): """Encode a 32-bit long as short/long pulses.""" result = [noparse][[/noparse]] for i in range(10): result.append(chr(0x92 | (value & 0x01) | ((value & 2) << 2) | ((value & 4) << 4))) value >>= 3 result.append(chr(0xf2 | (value & 0x01) | ((value & 2) << 2))) return "".join(result)It seems to encode the 32-bit word "value" into a an array of bytes "result", but it has been many years ago that I had a look at phyton, and this particular code segment is, I must confess, "write only" code for me. I can't make out if my guess how it the clock speed independed bit bang serial protocol works is correct. The original message said this code is "based on Chip's serial protocol description", so I suppose this protocol description describes the method used. Unfortunately the message does not state where to find it.
But anyway, I must confess that its only simple curiosity that lead me to speculate how such a timing independent bit banging serial reception routine could work, it's not that I want to write a driver for it myself.
KeithE's idea is interesting, the actual (firmware based) boot process is still done using the code in the EEPROM, but once the routine that is booted from EEPROM is running it can start another completely different serial (re-)boot process. The only potential problem is see might be that the firmware boot process might be confused by the re-boot software driving the serial port, so the re-boot PC driver must be started -after- a power on boot, of the propellor has booted it. Or the re-boot driver must open the serial port, wait for the processor to boot, and only then start the re-boot protocol.
Also, the re-boot routine could be used to get a rough estimate of the propellers internal clockspeed, so it could program the PLL to generate a standardized frequency, so for not too timing critical tasks you might be able to get decent timings out of the prop without the need for a crystal or resonator.
Mahjongg
If the Propeller is running off its internal RC clock, the clock is not stable or accurate enough to use for anything timing critical. Not only do we not know its frequency over a wide possible range, but the clock itself is quite temperature sensitive. Even if you could calibrate it, if the Propeller was just recently started, its clock speed could change quite a bit as the chip warmed up.
Once the boot routine finishes and the downloaded (either from Propeller Tool or EEPROM) program begins execution, pins 28-31 are already freed and appear as inputs.
KeithE's idea would work except that the system would have to continually recalibrate itself and there would have to be a nearly constant stream of data coming in. This can be done, but considering the price of crystals, you might as well put one in.
Okay, I took a look at the code, and it appears that indeed that data is encoded bitwise with a low going pulse with a length of either 1T for a '1' or to a low going pulse with a length of 2T for a '0', where 'T' is an undetermined amount of time. A serial port can send these pulses by either sending a '0001111' (0FH) or a '0000000' (00H) 7-bit character (including start bits its four bit times low, or eight bit times low). So that is quite close to what I thought was going on.
Also the bitstream encoder and decoder are using some kind of state machine using a linear feedback shift register to synchronize the bit-stream decoder, but thats beyond the scope of what I wanted to know. It's probably some variation of HDLC.
Your are right, even when the propeller's clock is calibrated by using some kind of external timing source, even the slightest temperature change will wildly change the clock speed. But then, some calibration might be better than none at all for some tasks.
Of course after the booting process has finished, the I/O ports are freed and can be re-used for your own (re-boot) driver, I only wanted to point out that you need to wait for the boot routine to determine that the serial boot routine is not trying to send code, before starting to send code over the serial port.
But I now think the boot code won't be easily confused by some garbage coming out of the serial port, and will just ignore it and continue booting by loading the 32K code block from the eeprom.
mahjongg.
P.S. I realised afterwards that actually the serial port should either send '0011111' = 1FH, or '0000011' = 03H characters because the '1' period must be at least as long as the shortest '0' period. So that is -exactly- what I had in mind.
Post Edited (mahjongg) : 3/9/2007 1:57:46 PM GMT
resident where? SD? EEPROM?
The object does not refer to the SD, if it would access the SD card that would be very convenient as an option... have two Props on a board with an SD card for the binary.
Granted Mike has already said the SD card can be written to the EEPROM with Femto, I'm just looking at all the possibilities.
The loader as written requires that the program to be downloaded is included as data in the program itself. The FILE directive does that. Since this program is included in the loader as data, it is stored in the boot EEPROM, then is copied to RAM during the boot process. The loader reads the bytes of the program from RAM for transmission to the other Propeller.