Stand-alone Programmer?
Seairth
Posts: 2,474
I'm looking for a stand-alone programmer (preferably console-based) that will take a .binary or .eeprom file and load it. Most importantly, I don't want it to validate the image at all. Just upload it. Does anything like that already exist? If not, I don't suppose there's documentation (other than reading booter.src) for the programming protocol.
Comments
I hadn't tried it because the documentation indicated that an ELF image was required. If that's not the case, I'll download it and try it.
Catalina's Payload
Heater recompiled a PropLoader for Raspberry Pi and also the Routers based on OpenWRT.
IIRC there is also a Prop Loader written in VB that Parallax released
There is also a Propeller PASM example.
I also have modules in my Propeller OS that will take a .BIN or .EEP image and write to the EEPROM or load into RAM.
Right, but the Propeller Tool verifies the image. I need a tool that will load binary without verifying the image.
Would a pc program to "touch" the checksum do the job? Think I may have done this when I was laying around with using an 4/8KB EEPROM
No idea if and how it works
That;s fantastic! I hope this works (will check shortly). As it happens to be, I'm writing an assembler in Python, so this will fit nicely! Thanks!
Here's an updated version of that script, which works with Python 3 (make sure to install PySerial). I've tested it with both the Propeller Demo Board and the P1V on the DE0-Nano. Note that I have changed the command-line a bit. You can:
NOTE: I'd really like to thank Remy Blank for doing the hard work on this. My contribution is minor compared to his.
I hadn't heard of BST. Here's the link for anyone else that may be interested: http://www.fnarfbargle.com/bst.html
That's okay. It may still be useful. I haven't looked into it yet to see how customizable it is (if at all).
The reason I asked for stand-alone programmers in the first place is because I wanted something that was more liberal than the Parallax Propeller Tool with respect to what could be uploaded, thereby allowing an easier time of changing the P1V code in ways that would result in incompatible binaries with the current Propeller.
Nicely done.
What is the upper Baud limit, for given Prop Clocks, P1 and P1V ?
I think a P1 boots from RC, (slow, and needs margins) but a P1V can boot faster ?
Most modern USB-serial devices allow many more actual BAUD choice than generic values - commonly seen is a 12M/N baud granularity.
I guess Python can also do this, as almost PC SW will pass baud as the value, & the driver works out how close it can get.
Propeller starts up with RCFAST, which can range between 8MHz and 20MHz (typ. 12MHz). The P1V, on the other hand, behaves a bit differently, I think. Based on tim.v, the P1V initially runs at 10MHz (which is roughly close to 12MHz). You can change this by modifying hub.v to set the initial value of "cfg" on reset.
Based on the code in loader.src, it looks like the limiting factor is that you need at least 64 clock cycles from the beginning of the stop bit to the beginning of the next start bit to ensure accurate timing measurement. Going from this number, the max baud rates would be:
Propeller
8MHz (RCFAST worst case) 125,000 bps
12MHz (RCFAST typical case): 187,500 bps
20MHz (RCFAST best case): 312,500 bps
P1V
10MHz (simulated RCFAST) : 156,250 bps
80MHz (modified hub.v): 1,250,000 bps
The PropPlug can handle speeds up to 3Mbps, so a modified hub.v would allow for a 1.25Mbps transfer rate. Note, however, that loader.src would also have to be modified to adjust the timeouts, or else the loader would time out in 1/4 the current time.
All this aside, though, I think you could safely use this technique in your own code for speeds up to 1Mbps (with effective data throughput of just under 1/3 the baud rate). And if you have a bit of extra registers, you might be able to unroll the receive code, which would give you a significant bump in speed. This assumes, of course, that the begin-of-stop-bit-to-begin-of-start-bit time is still the most computationally intensive part.
In the end, is it practical to use this "1N1" technique? Probably only under limited conditions: you only have access to serial (e.g. communication through the PropPlug), you can't run actual full duplex serial with 8 bits of data per frame, you need a vers small block of PASM, etc.
Here is an idea that would extend the timing window, and perhaps could enable overall faster downloading for larger programs...
Download a short "boot" program which
1. Launches, enables the xtal, and waits for a new download protocol at >= 115,200 baud.
The download program then sends data faster using this new protocol. A better CRC could be used.
Even at 115,200 baud, the second stage could download a full 8 bits per byte which is 11/4 = 2.75 times faster.
The loader could be smart and enable this 2 stage download only if the code length is above a certain size.
This would help when downloading over wireless which tends to use lower rates.
The other issue is using cheap USB-Serial dongles which either do not have DTR or RTS, and/or just don't have the transistor reset circuit.
I think a key element of the 1N1 is around the clock tolerance - this design even allows for significant CLK drift after the calibrate phase.
Most 8N1 Auto-baud designs send a 'U' or similar, and then expect a reasonably stable clock from the calibrate char.
A benefit of sticking with 1N1 is it works on all Props, but pushing the peak baud up as high as is practical/reliable gives a simple single number to change.
At the highest BAUD rates, on parts like FT232R, the 'sticker' value is not quite attainable, as more stop bits are inserted.
HS-USB parts can deliver the throughput, but they are in larger packages, more $$, and need a crystal.
P1V can boot directly from its RAM with predefined content and this is the fastest way to boot it.
As long as you don't mind the multi-minute compile and programming in Quartus every time you want to change that code.
And the boot time is only matter when you are using the system and not debugging it.