Shop OBEX P1 Docs P2 Docs Learn Events
Propeller development for non-Windows users — Parallax Forums

Propeller development for non-Windows users

Remy BlankRemy Blank Posts: 42
edited 2011-10-08 15:01 in Propeller 1
(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:
  • 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.
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
./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
«1

Comments

  • acantostegaacantostega Posts: 105
    edited 2006-12-23 14:28
    Cool! Together with Cliff's Propasm this makes non-windows development possible for assembly.
  • TrescottTrescott Posts: 5
    edited 2007-01-23 09:10
    Hey Remy,

    Let me start by saying THANK YOU!! turn.gif I don't use windows, I don't have a license for windows, and I don't want to use windows. Put simply, I don't want to have anything to do with windows. mad.gif

    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. sad.gif I spent two days learning Python: reading the documentation, reading through the tutorials, and looking over the Python Standard Library listings. Just to make sure, before I come whimpering back to the forum claiming that serial is not a standard module.

    Did you write serial too? Or did you download it from somewhere? Or have I just done a lousy job of researching. smilewinkgrin.gif
    Could you please provide the serial module?

    I really do appreciate all you have done.

    Trescott
  • Remy BlankRemy Blank Posts: 42
    edited 2007-01-23 18:32
    Trescott said...
    Your Python script imports serial. I don't have serial. sad.gif

    The package is actually called "pyserial", and you can find it here:

    pyserial.sourceforge.net/

    And... you're welcome smile.gif

    -- Remy
  • TrescottTrescott Posts: 5
    edited 2007-01-23 20:42
    Excellent !!

    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
  • rokickirokicki Posts: 1,000
    edited 2007-01-23 21:50
    Wow, I had no idea you could fry a regulator. I would have thought all three pins would have all sorts of protection. Oh well, sorry to hear that.
  • TrescottTrescott Posts: 5
    edited 2007-01-24 23:55
    LOL lol.gif

    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.
  • TrescottTrescott Posts: 5
    edited 2007-01-25 19:24
    Oops blush.gif I was wrong about the power regulator, I just had a short on my breadboard that I missed.

    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?

    roll.gifI am so Excited to be making progress! roll.gif

    --Trescott

    Post Edited (Trescott) : 1/25/2007 7:36:29 PM GMT
  • Remy BlankRemy Blank Posts: 42
    edited 2007-01-26 08:32
    Trescott said...
    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 (expletive)ume that my wiring is correct, what else could cause a checksum error, when the same program will upload to ram and run fine?

    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
  • Remy BlankRemy Blank Posts: 42
    edited 2007-01-26 11:55
    I have uploaded a new version in the first post of this thread. When specifying the -e switch to upload to the EEPROM, the loader checks if the file is exactly 32768 bytes long (the standard size for an .eeprom file generated by the Propeller IDE). If not, it generates the EEPROM image file internally and uploads it to the Propeller.

    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
  • hinvhinv Posts: 1,252
    edited 2007-01-27 03:33
    Remy, you rock!

    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
  • TrescottTrescott Posts: 5
    edited 2007-01-27 21:42
    turn.gif Wow Remy,

    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
  • Remy BlankRemy Blank Posts: 42
    edited 2007-01-28 12:37
    Trescott said...
    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!
    I intended to implement the functionality anyway. Your request just gave the me the little push I needed to actually get it done.

    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
  • Mike GreenMike Green Posts: 23,101
    edited 2007-01-29 18:14
    I too have had this problem. The problem with long programs is that the Propeller Tool expects a checksum within something like 10 seconds (according to a note posted months ago). If there are any slowdowns during the download, this timeout can be exceeded. Obviously, this is more problematic the closer to 32K of program that you get.

    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
  • Remy BlankRemy Blank Posts: 42
    edited 2007-01-30 08:42
    Mike Green said...
    I would suggest that you disable the automatic downloading of Windows updates and initiate those manually on a periodic basis instead.
    I would do that... except that I'm running Linux smile.gif

    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
  • Mike GreenMike Green Posts: 23,101
    edited 2007-01-30 15:08
    If you've got any experience with writing/modifying I/O drivers in Linux, you could take the existing FTDI drivers and modify them for the download process so that the driver takes care of the whole preamble/recognition and buffers the whole 32K image before it begins. It could be done as a control function so that the driver would function normally as well (for virtual com ports).

    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.
  • Remy BlankRemy Blank Posts: 42
    edited 2007-01-30 16:05
    Mike Green said...
    If you've got any experience with writing/modifying I/O drivers in Linux, you could take the existing FTDI drivers and modify them ...
    I do have experience with Linux device drivers, however, as Linus himself often says, this is something that is better done in userland. smile.gif

    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
  • Mike GreenMike Green Posts: 23,101
    edited 2007-01-30 16:19
    I don't seem to have encountered the timeout after reset, only the timeouts doing the LFSR check and during data downloading. This is using the Propeller Tool under Intel emulation and with Parallels Desktop, both with MacOS and the MacOS driver handling the USB-serial converter rather than the Windows driver (so there's some additional work transferring the serial data back and forth through Windows XP).
  • Remy BlankRemy Blank Posts: 42
    edited 2007-01-30 16:50
    I think we're talking about the same thing. The downloader (Propeller tool or other) cannot detect the timeout until it has sent the pseudo-random sequence and waits for the reply from the Propeller. But when you look at e.g. the demo board, depending on the application stored in the EEPROM, you can see pretty quickly if the Propeller has decided that there's no request for downloading, and has started the application.

    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
  • Mike GreenMike Green Posts: 23,101
    edited 2007-01-30 17:37
    Yes, that LFSR handshake really expects the PC to transmit full bore. Any delays at all and the timeout at the end fails.
  • A.C. fishingA.C. fishing Posts: 262
    edited 2007-03-02 23:47
    So...
    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

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

    Somebody said...
    -Never Underestimate the power of human stupidity.
    ·
  • rjo_rjo_ Posts: 1,825
    edited 2007-03-03 00:32
    Remy,

    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.
  • WernerWerner Posts: 14
    edited 2007-06-21 15:43
    In case the timing problems still exist, it may help to switch to real-time priority
    (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 BlankRemy Blank Posts: 42
    edited 2007-06-22 06:11
    Thanks for the advice, I'll see if I can integrate that.

    -- 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...
  • WernerWerner Posts: 14
    edited 2007-06-22 08:45
    Remy Blank said...
    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 smile.gif

    - Werner
  • Remy BlankRemy Blank Posts: 42
    edited 2007-06-22 10:21
    Werner said...
    Ah, that was the project with the little mobile terminals for conferences, wasn't it ? It's a small world smile.gif
    Yep, it definitely is.

    -- Remy
  • ehdynehdyn Posts: 5
    edited 2007-07-19 19:20
    I'm really wanting to learn spin, and the propeller. But I'm Mac only at the moment. I'm considering putting together a pc just for this purpose, but then I think of all of the different synths I could by with that money, and how I have no other use for a pc. Torn-maybe the prop2 will sway me.
  • Mike GreenMike Green Posts: 23,101
    edited 2007-07-19 20:33
    If you have an Intel Mac, either Parallels Desktop or VMWare's new virtualizer work with Windows XP and the Propeller Tool. If you have a PowerPC Mac, you can use Guest PC and Windows XP. Because Guest PC is emulated, it's a bit slow, but does work. On the Intel processor, the Propeller Tool works full speed.

    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.
  • Kevin WoodKevin Wood Posts: 1,266
    edited 2007-07-20 23:31
    >>> I'm considering putting together a pc just for this purpose, but then I think of all of the different synths I could by with that money, and how I have no other use for a pc.

    Cakewalk Sonar...
  • Paul BakerPaul Baker Posts: 6,351
    edited 2007-07-20 23:40
    There aren't many synths you can buy for < $300

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Paul Baker
    Propeller Applications Engineer

    Parallax, Inc.
  • Chuck RiceChuck Rice Posts: 210
    edited 2008-03-07 04:41
    Remy Blank said...

    * 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.

    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-


    .
Sign In or Register to comment.