p1load - a propeller loader
David Betz
Posts: 14,516
I've recently posted the sources to p1load to github. p1load is a command line program for loading Spin binaries. It also includes a module called ploader.c that implements the Propeller ROM loader protocol and can interface to any serial driver that can provide an appropriate interface. This interface currently consists of a tx() function to transmit a buffer of bytes, an rx_timeout() function that receives a buffer of bytes with a timeout, and a reset() function that resets the Propeller, usually by toggling the DTR signal.
p1load can be built for Mac OS X, Linux, or Windows.
GitHub URL: https://github.com/dbetz/p1load
p1load can be built for Mac OS X, Linux, or Windows.
GitHub URL: https://github.com/dbetz/p1load
p1load - a simple loader for the propeller - version 0.009, 2014-08-10
usage: p1load
[ -b baud ] baud rate (default is 115200)
[ -p port ] serial port (default is to auto-detect the port)
[ -e ] write a bootable image to EEPROM
[ -P ] list available serial ports
[ -r ] run the program after loading
[ -t ] enter terminal mode after running the program
[ -T ] enter PST-compatible terminal mode
[ -v ] verbose output
[ -? ] display a usage message and exit
file[,addr]... files to load
Comments
Sounds nice David, a multi-platform loader. Now is there any chance that this loader could implement a 2-stage process so that it would load a "eeprom loader", boot into that which would then continue to communicate with p1load to load in the actual image file which in my case would be a 64k image but it could be any size and offset perhaps. So we would have to have a setting somewhere to point to this eeprom loader or it could be made general enough that it would work with various crystals by default to PLL8x for instance and auto-baud.
Can you add read function?
Actually that EEPROM read function would be handy too as it would permit cloning easily. The read function would be part of the 1st stage loader which could run at much higher baud rates than 230400. I think you're onto something here David
+ Additional command line argument for EEPROM download size, in case if user want to download all data from 64KB EEPROM.
This isn't emergency, but could be nice feature.
Something I have thought about often is having a 2 stage loader.
1) Loads a small boot-style program into hub ram and then executes it --> becomes stage 2.
2) The loader can implement a number of features (and can be expanded upon quite simply)
Speed could be increased beyond115,200 baud
2a) EEPROM functions such as write an eeprom (lower 32KB), write upper 32KB (or partial) eeprom, execute lower or upper eeprom (could be expanded to support 128KB eeproms or even SPI Flash), could include reading back eeprom info
2b) Load hub ram and execute it. This could be a faster downloader which could also be capable of performing the 2a and 2b functions.
An obvious requirement is then for the loader to be able to jump into being a serial terminal (which you have already done).
The stage 2 loader/program could also be a monitor/debugger.
One last requirement I would like to see is the ability of the loader (pc end) to be able to go into a loop waiting for the user to reset the prop manually (or by an existing prop program issuing a software reset ie calling the booter rom). This would help remote over the air loading, and also loading using a simple usb-serial interface without requiring the transistor reset circuitry (or any DTR/RTS reset). This overcomes a propplug requirement.
None of this is complex in the Loader (pc end) as it's really already there. It just needs to provide the "hooks".
https://github.com/dbetz/p1load
Thanks,
David
You should be able to build the RaspberryPi loader by typing this command:
Good news is it compiles fine. The bad news is that both the GPIO pin used for reset, and the polarity of the reset, could vary.
On Propeller HAT, for example, it requires the GPIO to sit high, and then pulls low for a reset. It uses pin 17.
Also. I've tweaked the reversed states into the code, and tried to detect the Propeller HAT on /dev/ttyAMA0 to no avail. I'll have to get a scope on it at some point to verify the reset line is being asserted. I have used propeller-load and my Python loader successfully to verify it's not a hardware issue.
Yes, I should be able to help with this. I already attempted to port the GPIO reset code from pi-propeller-load to p1load without success, it just wouldn't work and I could not figure out why. This is the same situation I fear! Need to get the scope out and see what's happening.
I meant pi-propeller-load, which I have on my Pi, compiled and functioning. It was something of a hassle to get compiled though!
This is the module: http://www.100randomtasks.com/raspberry-icing
Edit: Never mind. Reading the documentation, he says you need to replace propeller-load with something downloaded from the Parallax forums. My guess is that this is Heater's version.
Heater: Did you hijack RTS for your GPIO reset code?
Thanks,
David
I believe this is Heater's original repository (I believe)
https://github.com/ZiCog/pi-propeller-load
I haven't built from here, so I don't know if it is working.
Hope this helps. I apologize if it is something you already are aware of.
It has been tested on Pi and MIPs based machines.
It allows selection GPIO number and reset polarity from command line options.
I could probably supply the binary if you want to use it to verify your setup?
I don't believe it has any dependencies, it should *just work*
Don't forget to specify GPIO pin and logic level with; -Dreset=gpio,PIN,low/high
I've added handling of the "-D gpio=17,0" option to p1load.
I've compared the source code from Heater's repository with what I have in p1load and can't find any significant differences.
However, p1load still isn't working on the RaspberryPi. :-(
I've pushed all of my changes to github but I'm not sure what to do next about getting this to work.
One thing that confuses me is that I need to use gpio,17,0 to get propeller-load to work on my RaspberryPi but the instructions that came with my Raspberry Icing module says it is using GPIO0 for reset.
Some USB-UART devices accept only the ancient Baud choices, but most modern ones (FTDI,Silabs) will accept any baud value, and give you the nearest HW supported value.
Usually they have a 12MHz virtual Baud Clock (FT2232H series have higher virtual baud clocks, and even better Baud Granularity, if that matters to you )
If you have a better USB-UART path, then other intermediate baud values should also work.