SOLVED: prop 1 loader for linux
prof_braino
Posts: 4,313
I found a bunch of tools that look like they might load prop 1 firmware eeprom images into the prop. But most look like they are not finished.
What is the current best tool and/ or released tool for loading an eeprom image into the prop under Linux?
EDIT: I was looking for supported, multi-platform (Linux, Windows, OSX), and command-line
Thanks!
Answers:
Official tool: propeller-loader in propgcc https://github.com/parallaxinc/propgcc
unofficial version of the same tool: https://github.com/dbetz/propeller-load
Unofficial tool: https://github.com/dbetz/p1load
What is the current best tool and/ or released tool for loading an eeprom image into the prop under Linux?
EDIT: I was looking for supported, multi-platform (Linux, Windows, OSX), and command-line
Thanks!
Answers:
Official tool: propeller-loader in propgcc https://github.com/parallaxinc/propgcc
unofficial version of the same tool: https://github.com/dbetz/propeller-load
Unofficial tool: https://github.com/dbetz/p1load
Comments
Tutorial
Source Code
If it would be helpful I can add it to my build server in order to provide binary images. Currently, I believe it is only supplied in binary form as part of a PropGCC package.
Heater has re-compiled it for the Raspberry Pi, and a TP-Link MR-3020 OpenWrt router hack.
The MR-3020 can be used as a wireless PropPlug that stores binaries, or can even compile them from Spin (Heater created that as well.) You use 'scp' (secure copy) to transfer files over to the MR-3020 wirelessly or on a LAN.
There is a question of what you are planning to use for interface -- RS-232 or USB. Both can do it, but take a different installation method.
+++++
Heater has ordered a bunch of VoCore devices for wifi PropPlugs. You may want to follow what he does with that. http://vocore.io/
the readme says: when I run the source setenv, is gives an error:
since the above failed, when I run the make file, it gives an error:
pf6b@pf6b-VirtualBox ~/propeller-load $ make TOOLCC: gcc CFLAGS: -Wall -Isrc/common -Isrc/runtime -Isrc/loader LDFLAGS: -Wall -Isrc/common -Isrc/runtime -Isrc/loader SPIN: bin//bin2c src/propeller-load.c: In function ‘main’: src/propeller-load.c:292:23: error: ‘PORT_PREFIX’ undeclared (first use in this function) ShowPorts(PORT_PREFIX); ^ src/propeller-load.c:292:23: note: each undeclared identifier is reported only once for each function it appears in make: *** [obj//propeller-load.o] Error 1 pf6b@pf6b-VirtualBox ~/propeller-load $What is missing?
Thanks!
https://github.com/ZiCog/pi-propeller-load
No guarantees though as most of it must be out of date compared to the latest work David Betz has done. Only ever tested for loading normal Spin binaries, none of that XMM and C loader stuff.
pf6b@pf6b-VirtualBox ~/propeller-load $ export OS=linux pf6b@pf6b-VirtualBox ~/propeller-load $ export PORT=/dev/ttyUSB0 pf6b@pf6b-VirtualBox ~/propeller-load $ export BOARD=hub pf6b@pf6b-VirtualBox ~/propeller-load $ make TOOLCC: gcc CFLAGS: -DLINUX -Wall -Isrc/common -Isrc/runtime -Isrc/loader LDFLAGS: -DLINUX -Wall -Isrc/common -Isrc/runtime -Isrc/loader SPIN: bin/linux/bin2c obj/linux/propeller-load.o obj/linux/loader.o obj/linux/lmm-image.o src/xmm-image.c: In function ‘BuildExternalImage’: src/xmm-image.c:58:18: warning: variable ‘initSectionTable’ set but not used [-Wunused-but-set-variable] InitSection *initSectionTable, *initSection; ^ obj/linux/xmm-image.o obj/linux/xmm-image2.o obj/linux/pex-image.o obj/linux/loadelf.o obj/linux/packet.o obj/linux/PLoadLib.o obj/linux/p1image.o obj/linux/config.o obj/linux/expr.o src/system.c: In function ‘xbAddProgramPath’: src/system.c:133:5: warning: implicit declaration of function ‘readlink’ [-Wimplicit-function-declaration] r = readlink("/proc/self/exe", fullpath, sizeof(fullpath)-1); ^ obj/linux/system.o obj/linux/port.o make: openspin: Command not found make: *** [obj/linux/serial_helper.binary] Error 127 pf6b@pf6b-VirtualBox ~/propeller-load $Next step?
https://github.com/parallaxinc/OpenSpin
I think that builds with a simple make command. After that you will have to put the openspin executable onto your PATH somewhere.
also from the above post I need to export the path to openspin executable
at this point I get an error (below), I think it might have to do with SD card or the memory model.
make runs fine until the very end:
I don't have any SD card, so I don't know where this came from.
When I run the propeller-loader executable on the firmware I created earlier with openspin, I get the message:
but at this point, the command prompt does NOT return, it just kind of hangs.
I can do a CTL-z and get back to the prompt,
I can use minimcom and get to the prop, and see the the firmware has in fact loaded, There is a version string in the firmware and I can load alternating versions.
Would the "propeller-load does not exit" issue be due to running in a virtual box?
Or would this be something to do with the propeller-loader (maybe the SD error message)?
Thanks, this has gotten me very far on upgrading my tool chain to the current tools.
Looks like your binary loaded and verified OK. I have no idea off hand why it does not exit at that point.
The propeller1 has not changed over the years, so maybe the old loader mentioned here still works:
http://forums.parallax.com/discussion/90707/propeller-development-for-non-windows-users/p1
Just tested on Debian8... ...and the program ran correctly after reset...
propeller-load has several options... Execute it on its own or with the "-?" option and you will get a list of options/parameters. Two of those ("-r", "-t") will allow running of the uploaded program/eeprom and displaying a terminal.
options -r, -t: -r = run/execute the program after upload -t = open a terminal session between the PC and the prop Example (upload the eeprom file, execute its program, & start a terminal session with the prop board): $ propeller-load -e StartKernel.eeprom -r -tdgately
So I guess I also have to do some kind of What propgcc executable exactly would the loader be looking for? There seems to be just under 80,000 items in propgcc. I didn't read (or find) all the documentation, but the readme did not seem to mention any of the set up stuff, aside from "run make". I ran make successfully (as far as I can tell), but nothing jumps out as my solution.
Thanks!
Thanks! I saw the terminal option, but we use minicom (linux) or teraterm (windows) for various reasons. And as stated, minicom works, the only concern is that the loader doesn't exit. I will of course try the terminal option after I address the loader to exit.
This is what I thought as well, but obviously it needs something else. Bear in mind that that this is a clean install of the OS, and a clean install of each tool, and I cannot rely on any of the tools to be previously configured and previously working. While all developers will have all the "other" tools set-up and in-place from previous years' efforts, any NEW user will be starting from close to scratch. Relying on previously set up anything will guarantee 100% failure of all new users lacking those unnamed tools.
I start each iteration of testing with a clean install of the OS, and follow the instructions step by step. It takes marginally longer but it really flushes out the details, as demonstrated here.
Nothing against you guys, your work is great! Me and the kids new just a tad more detail in the instructions.
Thanks, and thanks for your messages. But as stated, we want to use the most current tool if possible; we want to use exactly the same things everyone else is using so it works transparently on linux, osx, and windows, and anything else that these can be ported to. The project itself is different enough to have weirdness issues on its own. For anyone that hasn't guessed, this is all around setting up the physical propeller 1 to load simple spin programs, in support of the PropForth 6 build and test automation. The build and test automation works just fine, but it uses Brad's Spin Tool (bst) which has a bunch of problems (at least for this project). So going back to the old python loader could work, but would involve a bunch of "out-dated software" issues due to old version of python etc. This would of course be the next option, if the current tools prove to be unsuitable in some way, but my hope is that all issues can be solve via questions on this thread.
Use just the "-r" option... Have minicom running in another window or TAB of your editor, if possible. Or append "&" to let the loader run n the background while you execute minicom.
dgately
https://github.com/dbetz/p1load
Brilliant! the -r option did the trick. I didn't realize that the prop doesn't automatically start running with these tools. Our previous tool chain always resulted in the prop running, as soon as load completed, the prop would be visible when we launch minicom. Or maybe it didn't sometimes, and this was the problem with bst. Whatever, this is the final piece, I think the loader is 100% working now.
I will still try to solve the propgcc error message. I had hoped that propgcc, openspin, and propeller-loader would all be one happy package and just work together. Perhaps I need to work on something further up stream.
Yes well, add an editor and call it... Let's see... Something simple, hmm... Ah, "SimpleIDE"?
dgately
This was not clear from the available documentation, discussion threads, and responses to my questions (or maybe I'm a little dense).
I may have gone about this wrong way around. I started asking about compiling spin, then about loading the prop.
What I really want is one tool that will accomplish compiling (spin and anything else) and loading the prop from the command line so they can be used in a script. What ever tools must be currently supported and work transparently under linux, OSX, and windows. I think that openspin and propeller loader accomplish this, but I had been under the impressing that these should all be integrated into a single tool. Previously I though simpleIDE woudl be this tool, but found out that spin support was to be removed from simpleIDE. Later I though propellerIDE would be the tool except for the IDE part. I started looking at propgcc but could not figure it out, which lead me to ask "what’s the spin compiler and what’s the propeller loader". So here we are.
Can propgcc compile spin and load the prop 1 from the command line, i.e. in a script?
Most IDE's do not dictate which languages you can use ?
Parallax do have seem to have created much confusion here, with 'too many IDE disease'.
Other vendors grasp the support costs of Myriad options, and they have one IDE for multiple MCUs, rather than Multiple IDEs for one MCU ?!
I had hoped that SimpleIDE would be like that. Seems like there are plans afoot to move in that direction be removing Spin and other options.
I disagree that any command line tool should compile and program. Better to keep the tasks separated. An IDE can call them up as it needs and a user can script them together in a minute if need be.
- seems those web examples of Arduino Assembler must be wrong ?
Limiting user choice can give merely the illusion of simplicity, as then the web grows many
"How to workaround the imposed limitation..." example, and so long term confusion is actually greater.
This is what it think I have discovered:
We DO need OpenSpin to compile Spin code, no other CURRENT tool does this; if we want cross platform and supported, we want OpenSpin. Yes/No?
We DO need propeller-loader to load an image to the prop. Propeller-loader is included in propgcc, but has to be compiled separately, it is not done automatically in the highest level make; the make for propeller-loader is down under the loader directory. Propeller-loader is available separately, but still needs propgcc to be present or it given errors. The set up of both tools requires us to set up a bunch of environment variable with path names etc. but the setup is not defined in the documentation. Regardless, at least the compile finishes and the resulting executable functions to load the prop.
SimpleIDE does not include spin support in any form. This is C only for the prop. Yes/No?
PropellerIDE does not include spin support in any form. This is C only form the prop, and perhaps also for other parallax micro controllers, maybe Basic Stamps and P2? Yes/No/Actual list?
The important take away seems to be that no current parallax tools support SPIN aside from OpenSpin, indicating that spin is moving out of the main focus. For a project such as PropForth, which only uses SPIN to get to the FORTH kernel, it may be time to start thinking about having propforth generate a new forth kernel directly, rather than relying on and taking advantage of a SPIN compiler, as the SPIN tool chain is no longer the mainstream tool chain. Yes/No?
Thanks for answering these questions, as these answers will affect our roadmap starting now.
There is also a ParallaxIDE which is for chrome, for the BASIC STAMP, which I imagine would be prop basic. (I guess, I haven't been up that way for awhile.)
Hence my confusion.
Thanks to who ever was smart enough to use a descriptive name on the tools that I need!
And to the folks that name the other tools, good job on being as confusing as possible! I couldn't beat that if I tried!
Way off topic: In my humble opinion,
SimpleIDE should be "PropC-IDE"
PropellerIDE should be "PropSpin-IDE"
ParallaxIDE should be "BasicStampChrome-IDE"
Would these be meaningful names or do I still misunderstand?
No.
You insist in needing propeller-loader instead of looking at the alternatives.
If you just want to wrap your Forth kernels in some lines of Spin and want to get that into your Propellers and to be able to do that on various platforms, then you sure do not need/want a propeller-loader that forces you to build propgcc first.
Mike
This is a little confusing, as you say 'one tool', then 'tools' & seem to also expect Multiple Languages in that one Tool ?
You certainly can expect one script to compile and download, but one executable seems to be what you are hoping for ?
As others have mentioned it makes more sense to separate the Download part from the Compiler part. ie two executables.
That way the download is common and shared among all the languages that may create the file(s) to download.
A single script can easily manage this.
I have also seen Compilers with command line switches that call other downstream tools, but they still exist as multiple executables.