Propeller development for non-Windows users
Remy Blank
Posts: 42
(This is a repost. I guess the "Propeller and Operating System" sticky thread wasn't the right location to post this in the first place.)
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:
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 or VMware, 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: Uploaded new version that supports uploading .binary files to EEPROM.
Post Edited (Remy Blank) : 1/26/2007 11:50:07 AM GMT
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 and pyserial
- Tested on Linux and Windows (I know, the latter doesn't make sense; I have tested it anyway). I'd be happy to make it work on OSX, too, but I don't have a Mac to test.
$ ./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
./Loader.py -s /dev/ttyUSB2 vga_hires_text_demo.binary
Example: upload a .eeprom to the demo board's EEPROM
./Loader.py -s /dev/ttyUSB2 vga_hires_text_demo.eeprom
Personally, I use it in watch mode:
./Loader.py -s /dev/ttyUSB2 -w my_project.binary
Then I launch the Propeller IDE under Wine or VMware, 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: Uploaded new version that supports uploading .binary files to EEPROM.
Post Edited (Remy Blank) : 1/26/2007 11:50:07 AM GMT
Comments
Let me start by saying THANK YOU!!
I avoid using windows based produce as well, (being based on a bad system, they tend to inherit the same problems) so I don't use WINE much ether. Knowing that I have a low interest in such things it would not surprise you to know that my copy of WINE is broken (dependence issues) and I don't want to take the time to fix it. I would rather do some thing more productive.
I have been trying to find resources for working with the Propeller chip and the SX chip under linux for the last month or so. But have found it difficult to find any decent documentation for the Propeller and SX. From what I've read and seen, they seem like really good chips and Worth the trouble to get working under linux. I don't know where you got the info on the uploading protocols, I couldn't find them. I felt like I was running around in a maze. And was starting to think about looking more closely at alternatives.
Using Cliff Biffle's propasm program I can create the binaries.
(Find Cliff's propasm.jar here)
And now using your program I should be able to upload them to my Propeller chip.
I am almost there, just one little problem still standing in my way. Your Python script imports serial. I don't have serial.
Did you write serial too? Or did you download it from somewhere? Or have I just done a lousy job of researching.
Could you please provide the serial module?
I really do appreciate all you have done.
Trescott
The package is actually called "pyserial", and you can find it here:
pyserial.sourceforge.net/
And... you're welcome
-- Remy
It will run for me now. But I can't test it now, because I seem to have fried my 3.3V regulator chip! Ugh! It's been very dry here the last month or so, and I have been shocking myself with static electricity about 2 to 5 times a day. (or so it seems) I was afraid this would happen, and have been careful. (This is the first time I have actually damaged a component with static. Plenty of other ways but never before with static.) I hope I didn't get the Propeller chip too. (it cost more.)
Thanks again,
Trescott
Well I can't say for sure that's how I killed it. But I have gotten some nasty shocks. Ones you could see the flash even with all the lights on. And man, did they hurt. But I was surprised to find that the regulator stopped working. Any way, I am getting some more along with other goodies soon.
So, I tested uploading a program to the propeller chip and ....
SUCCESS!!! Yeah!!
Now I'm having a little fun with my chip.
But when I tryed to use the -e option to upload to the eepron I get a checksum error. I have double checked my wiring, and believe it to be correct, but i could be wrong again.
If we assume that my wiring is correct, what else could cause a checksum error, when the same program will upload to ram and run fine?
--Trescott
Post Edited (Trescott) : 1/25/2007 7:36:29 PM GMT
That's because you can't currently use the same .binary for uploading to eeprom. In the Propeller IDE, you would generate a .eeprom file instead of a .binary, its size would be exactly 32kB, and you could upload it to the eeprom.
It's actually quite straightforward to generate a .eeprom from a .binary, and I wanted to add this functionality to the loader, but haven't had the time yet. Give me a few hours, and I should be able to provide an update.
-- Remy
In short, there is no need for .eeprom files anymore. Just generate the .binary, and either upload it to the RAM, or to the EEPROM with the -e switch.
-- Remy
I can't wait to get a space cleared on my desk and try this out.
I pretty much feel the same way about Windows as Trescott
Thanks very much.
Doug
I think that's the best service I've ever gotten for a free product! I mention a problem, and in less then 24 hours you've programed in a fix. Nice!
But unfortunately, my Propeller chip is acting strangely, and I don't think it has to do with your program. It receives the program from the up-link, but doesn't run them. I haven't determent what the problem is yet, but I am working on it. It will be working fine, and then it will stop. I've been experimenting with solar cells seeing how many are needed to power the Propeller chip, etc. So I had wired up a solar array to test and plugged in the battery and Prop Clip and upload the program. Then take it out side and unplug the battery and begin my expirements, varying the lighting conditions and seeing what the limit is of the array. The Propeller chip was running a simple program. I had a pinto-buzzer wired up to pin 1 making a simple chirp at about 6Hz, just something to let me know that it was still running. So, when the Buzzer stops I would take it back inside and hook the battery and Prop Clip back up, and start over again. After 4 or 5 times, the upload would still complete successfully, but the program wasn't running. I tested the output on the pin, and it was not changing. I didn't change the chip wiring between tests.
After seeing your post, I downloaded the new version and pulled out my test board. I hadn't made any changes to it sense my last attempt to get it to work. So the first thing I tried was to test running a program normally. And it worked. I don't know why but it did. So I wired in the eeprom, and ran the same test to make sure everything was still working. And it failed, same problem. so I double checked my wiring and tried again, still nothing. So, I remove the eeprom, and try again, still not running.
So my chip's not working right. And can't give an honest test of your improvement.
I think I damaged the chip with all those Brown outs. ...I be needing more chips.
But I'm confident that your changes work. And I am happy to have them none the less.
Thanks,
Trescott
About your other problem: I have also had trouble programming my demo board from time to time. When uploading small programs (like 4kB or so), it works almost every time. But for longer binaries, and when programming the EEPROM, I sometimes have to try 4-5 times before the Propeller bootloader accepts the upload. It seems to be dependent on the load of the computer, e.g. if I run a Windows VM in parallel, the problem gets worse.
I suspect the problem comes from the timeout after the reset. The protocol specifies that DTR must be pulled low for at least 10ms, then the loader must wait for 100ms +-10%, then send a calibration pulse followed by a pseudo-random sequence, etc. The thing is, it is not possible to generate the 100ms timeout precisely, as all communication with the Propeller (setting DTR as well as sending data) goes through the USB port, which isn't deterministic. Making things worse, the kernel also adds a non-deterministic lag. The timeout is currently set to 90ms, the same value that the Propeller IDE uses, which seems to work more or less.
Some people have also reported the same problem with the Propeller IDE, i.e. they also get programming errors when they run background tasks at programming time.
Anybody has a good idea how to avoid this problem?
-- Remy
I used to run Windows XP under a PC emulator on a PowerPC Mac. It worked slowly, but pretty well until the programs got to be much over 16K, then might take 8-10 tries to download successfully. I found that if I ran anything else in the background (like you), the problem got worse. I now have an Intel Mac which can run Windows XP directly. I still have problems occasionally and have found that usually Windows is downloading an update of some kind. I would suggest that you disable the automatic downloading of Windows updates and initiate those manually on a periodic basis instead.
Mike
On a more serious note, I am thinking of making the download a two-step process, where the first step downloads a small bootloader using the ROM bootloader, and the second step downloads the memory content using a more resilient protocol (or rather, the same protocol but with larger or no timeouts).
-- Remy
If you're going to make a new downloader, you might as well use a better protocol like XModem or YModem with existing open source code. The Propeller boot loader's protocol is used mostly because the chip is running off the internal clock which is neither accurate nor stable enough for standard serial communication. That's why a ratiometric system is used. You should be able to require a crystal controlled clock and use the Full Duplex Serial driver at a fairly high Baud (like 38400 or 57600).
I think someone already wrote a simple XModem downloader for the Propeller for use with bitmaps for display. You might search the forum for it.
I like the current protocol, it's fast enough for most purposes (and I have got a few ideas how to make the upload even faster) and probably pretty simple to implement, the only thing that really bugs me is this timeout after releasing reset. I don't know how complex XModem or YModem are, but I'd guess it's more than the bootloader protocol. In any case, I'd really like to be able to run from the internal oscillator.
-- Remy
For example, I have a simple LED blinker in the EEPROM, and when I see a "reset timeout", the blinking starts even before the LFSR sequence has finished transmitting.
-- Remy
The only problem is I have no .binary files. Could someone attach some Propellor .binary file for the demo board just to make an LED blink as an example?
So, in reality, what exactly do you send to the demo board in a simple program? Like what exactly gets sent down COM3 if I wanted to make the propellor blink an LED? I can work on a Java GUI compiler in Eclipse(Which I think most Linux comes with, and I know Fedora 6 comes with) if I understand this part.
Thanks,
ACfishing
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·
I have always been a Mac guy... up to a certain point I purchased every flavor of computer that Steve Jobs produced... including a Next. So, I think I am about as avid a Mac fan as there is... I think Apple's engineers should take it from where you have it... and if they do, I'd be more than happy to keep all my work on my Mac. But 90% of the world seems to use Windows. And if anyone is considering a Prop but is put off by Windows... forget it. The Propeller is worth more than the computer it is attached to.
There is a lot to learn and the best way to learn is by doing. So, if you'all are just waiting for a Unix distribution on this... get real. Windows just isn't that hard to figure out and there are plenty of people here to help you.
Other than getting Remy at job at Apple... I have no real reason for this post.
Rich
Remy... you can always tell Mr. Jobs that I sent you. It won't help. But you can tell him.
(combined with mlock'ing the program into RAM) for the critical parts. This helps
against competing user space activity. You could still have trouble in the USB
subsystem, though.
An example (in C) for entering and leaving real-time priority can be found in
prog/rt.c of m8cutils.sourceforge.net/m8cutils-22.tar.gz
The functionality used is defined within POSIX, but optional. I don't know how
you'd do this in Python, or if the Python run-time would add any snags.
- Werner
-- Remy
PS: Are you the m8cutils maintainer? If you are, then we have met at EPFL quite a long time ago, about porting Linux to the EP7211 ARM controller. Good ol' times...
Ah, that was the project with the little mobile terminals for conferences, wasn't it ? It's a small world
- Werner
-- Remy
I have tried the Propeller Tool with the commercial version (CodeWeavers') of Wine on an Intel Mac. It does work ... sort of. I wouldn't try to do it this way unless you want to fiddle a lot.
VMWare does have other Linux based versions, but I haven't tried them.
There are no non-Windows versions of the Propeller IDE.
Cakewalk Sonar...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
It works like a champ on Intel Mac OS x 10.5.2.
One Question. Once I get the watch mode started, how do I stop it? -Chuck-
.