Shop OBEX P1 Docs P2 Docs Learn Events
C program for uploading to the Propeller under Linux? — Parallax Forums

C program for uploading to the Propeller under Linux?

bifferosbifferos Posts: 11
edited 2010-01-26 11:17 in Propeller 1
The Python Loader.py program seems to run too slowly on my 150MHz cpu, so I've hacked together something that seems to work in C sites.google.com/site/bifferboard/Home/howto/serial-terminal-project/parallax-propeller-investigation (see attachments at the bottom). The problem is it's not 100% reliable, and tends to almost always fail the very first time the Prop is switched on, thereafter it works most of the time.

I'm just wondering if I'm re-inventing the wheel and if there's something better around that can be used on a really low-spec Linux machine.

thanks in advance,
Biff.

Comments

  • BradCBradC Posts: 2,601
    edited 2010-01-25 00:41
    bifferos said...
    The Python Loader.py program seems to run too slowly on my 150MHz cpu, so I've hacked together something that seems to work in C sites.google.com/site/bifferboard/Home/howto/serial-terminal-project/parallax-propeller-investigation (see attachments at the bottom). The problem is it's not 100% reliable, and tends to almost always fail the very first time the Prop is switched on, thereafter it works most of the time.

    I'm just wondering if I'm re-inventing the wheel and if there's something better around that can be used on a really low-spec Linux machine.

    thanks in advance,
    Biff.

    If the machine is an x86 you could try bstl.

    www.fnarfbargle.com/bst.html

    I'm not sure how its going to do on a processor that slow, but it certainly works on my very low spec PPC G4.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Life may be "too short", but it's the longest thing we ever do.
  • RossHRossH Posts: 5,519
    edited 2010-01-25 00:47
    Hi Biff,

    I probably can't help you get it working (but I'm fairly sure others in this forum can!), but when it is working reliably I would like to use your program in Catalina - writing one of my own was on my "to do" list but hadn't yet percolated to the top.

    One thing - your program doesn't contain any license terms. Did you intend it to be public domain? Of course I would credit you in any case, but you might like to consider issuing it under at least an MIT license.

    Ross.

    Edit: Probably should have mentioned that I would be intending to distribute a slightly modified version of your program that allows Catalina XMM programs to be loaded directly from a PC (as well as ordinary SPIN/PASM or LMM programs).

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Catalina - a FREE C compiler for the Propeller - see Catalina

    Post Edited (RossH) : 1/25/2010 12:52:16 AM GMT
  • BradCBradC Posts: 2,601
    edited 2010-01-25 01:02
    Looking at your code I can see 3 things that might help.

    - Try a slower baud rate. hippy demonstrated it working pretty reliably as low as 4800 baud from memory. Certainly 9600 or 19200 should work.
    - Try resetting the prop twice at the start. DTR Low ; pause 15ms ; DTR high ; pause 15 ms ; DTR low ; Pause 15 ms ; DTR High ; pause 95ms ; Load
    - Try pre-calculating your longs into an array and just squirting them out in chunks big enough to fill the buffers in the kernel or UART (in your case as you are writing raw I guess).

    Thanks for the mention of bst too! Crashes are never random. They are caused by bugs.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Life may be "too short", but it's the longest thing we ever do.
  • bifferosbifferos Posts: 11
    edited 2010-01-25 01:12
    RossH said...

    One thing - your program doesn't contain any license terms. Did you intend it to be public domain? Of course I would credit you in any case, but you might like to consider issuing it under at least an MIT license.

    If you have a use for it, go ahead.

    Biff.
  • bifferosbifferos Posts: 11
    edited 2010-01-25 10:13
    BradC said...
    Looking at your code I can see 3 things that might help.

    - Try a slower baud rate. hippy demonstrated it working pretty reliably as low as 4800 baud from memory. Certainly 9600 or 19200 should work.
    - Try resetting the prop twice at the start. DTR Low ; pause 15ms ; DTR high ; pause 15 ms ; DTR low ; Pause 15 ms ; DTR High ; pause 95ms ; Load
    - Try pre-calculating your longs into an array and just squirting them out in chunks big enough to fill the buffers in the kernel or UART (in your case as you are writing raw I guess).

    Thanks for the mention of bst too! Crashes are never random. They are caused by bugs.

    Thanks for the tips Brad! I will try these tonight. I have a 16550 UART, so it's got a FIFO (which is enabled), but that's it as far as buffering goes.

    Top speed is something I was wondering about - what is the fastest speed I can send stuff to the Prop, assuming *my* timing is perfect? I was planning, once I got this working, to write some x86 assembler to send even faster than 115200 using IO port reads from port 0x80 to do the pulse timing (which is what I'm using now), however it sounds like that's not a great idea. Since I plan to have a kind of BIOS-extension loading the program code, it needs to transfer the information to the Prop really quickly, i.e. there should be no discernible delay for the user, hence the need for speed.

    regards,
    Biff.
  • BradCBradC Posts: 2,601
    edited 2010-01-25 13:44
    bifferos said...

    Thanks for the tips Brad! I will try these tonight. I have a 16550 UART, so it's got a FIFO (which is enabled), but that's it as far as buffering goes.

    Top speed is something I was wondering about - what is the fastest speed I can send stuff to the Prop, assuming *my* timing is perfect? I was planning, once I got this working, to write some x86 assembler to send even faster than 115200 using IO port reads from port 0x80 to do the pulse timing (which is what I'm using now), however it sounds like that's not a great idea. Since I plan to have a kind of BIOS-extension loading the program code, it needs to transfer the information to the Prop really quickly, i.e. there should be no discernible delay for the user, hence the need for speed.

    bst[noparse][[/noparse]cl] uses 230,400 baud with the -f command line. That is pushing the limits as you need to add an extra pacing bit at the end of each long to give the bootloader time to write it out to the hub. This fault only becomes apparent here if the ambient temperature is above about 40 Degrees C (the internal RC oscillator slows down). This will only be a problem if you use dense packing, or you bit bang. I'm pretty sure the standard long into 11 bytes packing does not suffer from this as there is wasted space at the end of each long.

    I'd really have a crack at using the serial driver in the kernel and seeing how good its buffering is. If you pre-calculate your longs into one huge array, just stuff them into the kernel in a couple of big write() calls and let the kernel sort it out for you. It's what it's there for.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Life may be "too short", but it's the longest thing we ever do.
  • bifferosbifferos Posts: 11
    edited 2010-01-26 11:17
    BradC said...


    - Try a slower baud rate. hippy demonstrated it working pretty reliably as low as 4800 baud from memory. Certainly 9600 or 19200 should work.
    - Try resetting the prop twice at the start. DTR Low ; pause 15ms ; DTR high ; pause 15 ms ; DTR low ; Pause 15 ms ; DTR High ; pause 95ms ; Load
    - Try pre-calculating your longs into an array and just squirting them out in chunks big enough to fill the buffers in the kernel or UART (in your case as you are writing raw I guess).

    Hello again Brad. I've tried your suggestions, and my upload program works perfectly @115200. Unfortunately, I've reverted the changes, and it still works perfectly [noparse]:([/noparse]. I think it might have been temperature-related, because it was a lot cooler last night. Anyhow, I'll keep these ideas in mind next time I have a problem (want to see it break again so I understand why).

    thanks,
    Biff.
Sign In or Register to comment.