I just wanted to mention that I have had limited success using the Propeller Tool under wine-0.9.26. The tool installs cleanly and starts ok. However, when trying to open a path in the folder tree, I get an "Access violation at address 004DD514 in module 'Propeller.exe'. Read of address 00000005.". Then an item with an empty name appears in the folder tree. The application continues working however, and I'm able to open projects, edit and compile them. But I haven't found a way to make the eval board's USB visible to the tool. The "Identify hardware..." menu always leads to a "Error receiving ports GUID. Error #0.".
This means that it is probably possible to use the tool under wine for development and compilation, and to use the Python tool I have seen posted here to upload the binary to the Propeller.
I have also tried using the Propeller Tool under Win2k on VMware Player. The latter has an option to remove USB devices from the host and make them visible to the client OS. This mostly works, except that I get timeouts about 8 times out of 10. Half of the time, the Propeller just isn't detected, and the other half I lose the connection while verifying the RAM. But I did manage to upload some of the demos.
I would like to add that I am very interested in getting the Propeller Tool or something equivalent to work on Linux, as it is my only work platform. I have some time on my hands, and I would be willing to spend some time helping to achieve this goal, if any help is needed.
Here's something for non-Windows users. I have implemented a code uploader command-line tool, based on Chip's serial protocol description. Here's a list of features:
Command-line only, no GUI
Upload to RAM or EEPROM
Accepts both .binary and .eeprom files as generated by the Propeller IDE
Watch mode: checks the file to upload every second, and uploads it if it has changed
Requires Python 2.4
Tested on Linux and Windows (I know, the latter doesn't make sense; I have tested it anyway). I'd be happy to know if it works on OSX, too.
Download the attached script, and mark it as executable. For help on the command-line parameters:
$ ./Loader.py -h
Usage: Loader.py [noparse][[/noparse]options] path
Parallax Propeller uploader
Copyright (C) 2007 Remy Blank
Options:
-d N, --delay=N In watch mode, wait N seconds after detecting a file
change before uploading. The default is 1.0.
-e, --eeprom Program device EEPROM. The default is to program the
EEPROM when the path ends with '.eeprom'.
-h, --help Show this help message and exit.
-n, --no-run Don't run the code after upload.
-r, --ram Program device RAM. The default is to program the RAM
except if the path ends with '.eeprom'.
-s DEVICE, --serial=DEVICE
Select the serial port device. The default is
/dev/ttyUSB0.
--version Show the program version and exit.
-w, --watch Continuously watch the file and program if it changes.
Example: upload a .binary to the demo board on /dev/ttyUSB2
Then I launch the Propeller IDE under Wine, and to upload a new version to the board, I compile with Ctrl-F8, then Alt-B to "Save Binary File", ENTER to accept the proposed name, and finally ENTER to confirm replacing the old version.
If I could make a suggestion for the next revision of the Propeller IDE, I would propose an option to always have the .binary and .eeprom generated in the same folder as the top object file. This would make uploading a new version as simple as Ctrl-F9.
I hope this will help other people who have a non-Windows platform as a development workstation.
Cliff Biffle wrote an assembler for the propellor chip in Java, it's available at http://www.cliff.biffle.org/software/propeller/propasm/ combined with the command line tool mentioned above, things could be run under non window platforms.
I appreciate why some of the folks here want to see a Java version of this, however, in my experience as a Java programmer, a hobbyist, and an electrical engineer, as well as someone with extensive experience in Windows, *nix, and the Motorolla-based Mac, Java is rarely the way to go.
"Cross-platform development" --sure, but in the time it takes you to get all that cross platform compatibility actually working as planned, I'll have 3 versions of mine compiled and ready to go.
"Fast enough" --sure it is. So is a dump truck in low range if you've got time to waste.
I'm not bashing, I just question the logic of using a rather poor example of a programming language as a shining example of cross-platform development (I've had java apps refuse to run on different machines running the same OS, while running on another completely different OS just fine).
As a bonus feature, if the Parallax developers think best in a low-level language, which is logical given their profession, then ASM should be their language of choice. I program x86 assembly myself, and can understand exactly why they chose to use that.
I really like what they're doing, and believe that more focus on native compilers for different platforms (something like what FASM has done) will clear up any angst felt by the community.
Comments
This means that it is probably possible to use the tool under wine for development and compilation, and to use the Python tool I have seen posted here to upload the binary to the Propeller.
I have also tried using the Propeller Tool under Win2k on VMware Player. The latter has an option to remove USB devices from the host and make them visible to the client OS. This mostly works, except that I get timeouts about 8 times out of 10. Half of the time, the Propeller just isn't detected, and the other half I lose the connection while verifying the RAM. But I did manage to upload some of the demos.
I would like to add that I am very interested in getting the Propeller Tool or something equivalent to work on Linux, as it is my only work platform. I have some time on my hands, and I would be willing to spend some time helping to achieve this goal, if any help is needed.
- Command-line only, no GUI
- Upload to RAM or EEPROM
- Accepts both .binary and .eeprom files as generated by the Propeller IDE
- Watch mode: checks the file to upload every second, and uploads it if it has changed
- Requires Python 2.4
- Tested on Linux and Windows (I know, the latter doesn't make sense; I have tested it anyway). I'd be happy to know if it works on OSX, too.
Download the attached script, and mark it as executable. For help on the command-line parameters:Example: upload a .binary to the demo board on /dev/ttyUSB2
Example: upload a .eeprom to the demo board's EEPROM
Personally, I use it in watch mode:
Then I launch the Propeller IDE under Wine, and to upload a new version to the board, I compile with Ctrl-F8, then Alt-B to "Save Binary File", ENTER to accept the proposed name, and finally ENTER to confirm replacing the old version.
If I could make a suggestion for the next revision of the Propeller IDE, I would propose an option to always have the .binary and .eeprom generated in the same folder as the top object file. This would make uploading a new version as simple as Ctrl-F9.
I hope this will help other people who have a non-Windows platform as a development workstation.
-- Remy
EDIT: I have started a separate thread about the loader: http://forums.parallax.com/showthread.php?p=622354
EDIT: Removed attachment. Please download the up-to-date version in the thread above.
Post Edited (Remy Blank) : 1/26/2007 11:52:48 AM GMT
I'd like to propose a file -> "Save Rev Change" option.
It could simply check if the last digit was a number (or even letter). If yes, sequence, then save.
Every day I sit down and work on an object, I go through that exact same sequence. Man, would it help me.
Possible?
Thanks,
-Parsko
"Cross-platform development" --sure, but in the time it takes you to get all that cross platform compatibility actually working as planned, I'll have 3 versions of mine compiled and ready to go.
"Fast enough" --sure it is. So is a dump truck in low range if you've got time to waste.
I'm not bashing, I just question the logic of using a rather poor example of a programming language as a shining example of cross-platform development (I've had java apps refuse to run on different machines running the same OS, while running on another completely different OS just fine).
As a bonus feature, if the Parallax developers think best in a low-level language, which is logical given their profession, then ASM should be their language of choice. I program x86 assembly myself, and can understand exactly why they chose to use that.
I really like what they're doing, and believe that more focus on native compilers for different platforms (something like what FASM has done) will clear up any angst felt by the community.