Shop Learn
Can't Wait for PropGCC on the P2? - Page 17 — Parallax Forums

Can't Wait for PropGCC on the P2?

1141517192026

Comments

  • ersmith wrote: »
    I'd try doing an LED blinking program (or even one that just lights up an LED) first. It's also worth trying the -SINGLE flag to loadp2 to use the single stage loader, which is simpler than the multi-stage one. The main drawback of -SINGLE is that you have to do the clock setup yourself in your main program, but that's not too big of a deal.

    There were definitely some hoops we had to jump through to get loadp2 working on Linux (the Linux kernel insists on manipulating the DTR pin when the baud is changed, which can lead to the P2 being reset immediately after the program is loaded). I wouldn't be surprised if there's some similar but slightly different issue on the Mac.
    This is odd. Why don't the P1 loaders have this problem? I thought the P2 loader protocol was supposed to be easier to use than the P1 protocol. I don't recall doing anything special to switch baud rates after a load on the P1 on Linux or the Mac.

  • evanhevanh Posts: 11,276
    The problems with loadp2 have mostly been around reset polarity and timing and lack of knowledge over when DTR is toggled by the OS/libraries.

    I haven't tried to work out why -SINGLE wasn't the default. Actually, I haven't even tried using it.
  • evanhevanh Posts: 11,276
    edited 2019-01-23 03:33
    Maybe it was more about needing higher sysclock for reliable 2 Mbps when bit-bashed.

    EDIT: No that doesn't add up either. The Prop2 Doc says it can load up to 2 Mbps native.

  • evanh wrote: »
    Maybe it was more about needing higher sysclock for reliable 2 Mbps when bit-bashed.
    I'm not even using that high baud rate. I'm using "-b 115200 -l 115200". The 2M baud rate doesn't seem to work on the Mac.

  • samuell wrote: »
    Well, I had the impression that PropGCC, as used in SimpleIDE, had two flavors of printf(). To my knowledge, Dave is using the simplified version, if I recall correctly. As for the mechanics, I didn't know it was a wrapper.
    There are various printf implementations in the PropGCC libraries. The "standard" one in the latest propgcc libs supports long long and float, and we should be able to port it to p2gcc and/or fastspin.
    Regarding your last statement, it makes sense that tools need to be developed first. I'm not developing final software either, but I want to explore the possibilities. One of them was experimenting with the prime number program, which is practically done, despite the crudity of the code and the need for some fixing. Other possibility is testing and doing things using smart pins.
    It's definitely helpful to have demo programs for us to try out, so thanks for your primos example! I'm still working on 64 bit integer support for fastspin, so it won't run there yet, unfortunately -- but having a concrete program that someone wants to try gives me a good target for developing the 64 bit code.

    Regards,
    Eric

  • Dave Hein,
    I understand what you said. At this time I will stick with spin2gui, but I also would like a simple p2pasm subroutine that I can access in Peanut. I am not real adept at asm language but am working on it. I have the one from cluso99 and another that is from Parallax P2-EVAL (P2ES chip) pcb demo code, unfortunately I am having a difficult time learning the format and syntax. Steep learning curve. If you or anyone has some code to access the PST that shows easy access to print to the display it would help. Something starting with just printing a variable that shows me how to access the serial terminal directly it would help.

    Thanks

  • evanhevanh Posts: 11,276
    Ah, the staged-loader does a raw binary transfer of the main program. For large programs, this has a notable speed advantage over -SINGLE which uses three serial characters per stored binary byte. -SINGLE could be recoded to use base64 acsii mode instead. That'd be efficient enough to ditch the staged-loader method.
  • David Betz wrote: »
    Does someone have a cheat sheet showing how to get a program that writes to the console serial port working on the Mac? I've been trying to use Eric's fastspin to compile the code but I don't see any output when I load it with loadp2. Does loadp2 give some indication of whether the load worked? Would I get an error if it failed like I do on the P1? I tried this command:
    loadp2 -p /dev/tty.usbserial-P2EEQXU -b 115200 -l 115200 test.binary -t
    

    Somebody suggested trying the -SINGLE option. The command line would be
    loadp2 -p /dev/tty.usbserial-P2EEQXU -b 115200 -l 115200 test.binary -t -SINGLE
    
    Did you try that? Maybe you could post your test.binary so that other could try it on other machines just to make sure it works.
  • Dave Hein wrote: »
    David Betz wrote: »
    Does someone have a cheat sheet showing how to get a program that writes to the console serial port working on the Mac? I've been trying to use Eric's fastspin to compile the code but I don't see any output when I load it with loadp2. Does loadp2 give some indication of whether the load worked? Would I get an error if it failed like I do on the P1? I tried this command:
    loadp2 -p /dev/tty.usbserial-P2EEQXU -b 115200 -l 115200 test.binary -t
    

    Somebody suggested trying the -SINGLE option. The command line would be
    loadp2 -p /dev/tty.usbserial-P2EEQXU -b 115200 -l 115200 test.binary -t -SINGLE
    
    Did you try that? Maybe you could post your test.binary so that other could try it on other machines just to make sure it works.
    Yes, I tried that command. Maybe there is something wrong with my board. Anyway, here is the program I've been trying to load most recently. It's one I built with fastspin.

  • Samuel, I modified printf so that it now can handle long long variable. I checked these changes into GitHub earlier this evening. I also added cogstart.c and the other files to the library. If you can, try getting a fresh copy of the p2gcc project from GitHub. With the latest updates you can run your program by just typing "p2gcc -r -t primos.c". I also included the __umoddi3 function in the library, so you don't need that in your code anymore.
  • evanhevanh Posts: 11,276
    edited 2019-01-23 04:19
    David,
    Did you see my suggestion of adding an in-program delay before the printf()?

    Ignore that, just tested your demo and I see it is looping ...
    evanh@controlled:~/hoard/coding/prop2/testing$ ../bin/loadp2 -v -p /dev/serial/by-id/usb-Parallax_Inc._Propeller_P2-EVAL-ES_P2EEL5T-if00-port0 -t cdemo.binary -CHIP                                                                        
    Setting user_baud to 115200
    Set loader_baud to 2000000
    Setting clock_mode to 12427f8
    Loading cdemo.binary - 3296 bytes
    cdemo.binary loaded
    [ Entering terminal mode.  Press ESC to exit. ]
    toggle 0
    toggle 1
    toggle 2
    toggle 3
    toggle 4
    toggle 5
    toggle 6
    toggle 7
    toggle 8
    ...
    
  • evanhevanh Posts: 11,276
    P58 LED is flashing away non-stop as well.
  • Dave HeinDave Hein Posts: 6,322
    edited 2019-01-23 04:27
    Here's the output I get from the program using my Windows box.
    $ loadp2 -b 115200 -l 115200 cdemo.binary -t -v -p com4 -SINGLE
    Loading cdemo.binary - 3296 bytes
    cdemo.binary loaded
    ( Entering terminal mode.  Press Ctrl-] to exit. )
    fastspin C demo
    toggle 0
    toggle 1
    toggle 2
    toggle 3
    
    It also works if I specify -CHIP. However, it doesn't work if I don't specify a load mode. I'll have to look into that. I also noticed that if I specify a bad file name it still goes into the terminal mode.
  • My point is, if this is an engineering sample and was designed to run code at 180Mhz and were testing it at 80Mhz then we are not really testing it.

    We need to be generating production test code to test how this sample will work in the field. Does it get hot running at the designed frequency? Does that test function blink the LED at the correct timing?

    It looks like right now the Baud rate doesn't work.

    Mike
  • Dave Hein wrote: »
    Here's the output I get from the program using my Windows box.
    $ loadp2 -b 115200 -l 115200 cdemo.binary -t -v -p com4 -SINGLE
    Loading cdemo.binary - 3296 bytes
    cdemo.binary loaded
    ( Entering terminal mode.  Press Ctrl-] to exit. )
    fastspin C demo
    toggle 0
    toggle 1
    toggle 2
    toggle 3
    
    It also works if I specify -CHIP. However, it doesn't work if I don't specify a load mode. I'll have to look into that. I also noticed that if I specify a bad file name it still goes into the terminal mode.
    I tried this:
    loadp2 -b 115200 -l 115200 cdemo.binary -t -v -p /dev/tty.usbserial-P2EEQXU -SINGLE
    
    and still no luck. Do I have to have the jumpers on the P2-Eval board set in a particular way? I haven't changed anything since Parallax shipped me the board. Has anyone gotten loadp2 to work on the Mac?
  • iseries wrote: »
    My point is, if this is an engineering sample and was designed to run code at 180Mhz and were testing it at 80Mhz then we are not really testing it.

    We need to be generating production test code to test how this sample will work in the field. Does it get hot running at the designed frequency? Does that test function blink the LED at the correct timing?

    People are testing the P2 at a variety of frequencies and baud rates. David Zemon posted some code earlier in this thread to show how to change the frequency at run time in p2gcc, and the fastspin samples show how to do the same in fastspin.

    I agree that it'd be nice to change the default to a higher frequency, but *any* default will restrict the testing. People should be encouraged to play with different clock settings (and baud rates) to see what works. So I wouldn't get too hung up on what the compiler or loader's default is. I would encourage everyone to set explicit frequencies in their programs.
    It looks like right now the Baud rate doesn't work.

    Why do you say that? I've tried a variety of different baud rates with loadp2 and fastspin with success. If you're referring to printf in p2gcc (a very specific case) then I'm sure it can be changed to use another baud rate. Dave has posted the source code in his git repo. Look in lib/putch.c and change the 80000000 and 115200 to your desired clock speed and baud rate. Or better yet, write your own serial routines -- that will probably exercise some different paths to the standard ones, and test the chip even more!

  • Hi,

    Here is a new version of the prime number calculation program, provided in the zip file attached. It should run without issues at 160MHz. To compile it, just run the shell script.

    I tried to implement David Zemmon code "common.c" and "common.h", but the compiler started complaining about variable redefinitions. So, in the mean time, 160MHz it is!

    Kind regards, Samuel Lourenço
  • Dave HeinDave Hein Posts: 6,322
    edited 2019-01-23 13:19
    iseries wrote: »
    My point is, if this is an engineering sample and was designed to run code at 180Mhz and were testing it at 80Mhz then we are not really testing it.

    We need to be generating production test code to test how this sample will work in the field. Does it get hot running at the designed frequency? Does that test function blink the LED at the correct timing?

    It looks like right now the Baud rate doesn't work.

    Mike
    I have seen several people posting test code that runs at frequencies higher than 180MHz. The VGA programs tend to run at high frequencies. I posted a program called vgastuff that runs at 250MHz that is mostly written in C and uses p2gcc to build it.

    As I pointed out, p2gcc has a few complications with running at a frequency other than 80MHz. It currently requires building the binary and then running loadp2 separately. Also the terminal baud rate changes with the clock frequency. I hope to fix those issues today.
  • Ok, I replaced your "prefix.spin2" with "P2EVAL.spin2" and change the clock frequency to 180Mhz.

    Change the program to compile this new prefix and it seem to run the modified blink program at then new speed.

    Tried to change putch/getch to 180Mhz but that's not working.

    Mike

  • samuell wrote: »
    Hi,

    Here is a new version of the prime number calculation program, provided in the zip file attached. It should run without issues at 160MHz. To compile it, just run the shell script.

    I tried to implement David Zemmon code "common.c" and "common.h", but the compiler started complaining about variable redefinitions. So, in the mean time, 160MHz it is!

    Kind regards, Samuel Lourenço

    I tried the new program, and hangs after calculating several prime numbers if I specify a maximum of 100000. It works fine for smaller numbers. If I increase the stack size from 56 to 57 or more it works for a max 100000. I added my check_stacks code, and it reports 56 used even for a max of 100000. I even printed out the first few ints of the stack to make sure check_stacks is working correctly. I'm not sure what is causing the hang up, but a stack larger than 56 seems to fix it.
  • I'm still trying to figure out why my loads aren't working and it occurs to me that maybe it's a power problem. Is it okay to just power the P2-Eval board with the USB cable connected to the PC or do I need to also use a higher current USB power supply plugged into the other USB connector?
  • Never mind. Fixed the code so all is good.

    Now compiles all program as 180Mhz and works great.

    Added tools library which contains the pause function so I don't have to use waitcnt anymore.
    #include <stdio.h>
    #include <propeller.h>
    
    void main(void)
    {
        int i;
    
        pause(10000);
    
        for (i = 1; i <= 10; i++)
        {
            pause(1000);
            printf("Hello World - %d\n", i);
        }
        printf("Goodbye\n");
    }
    

    Mike
  • Mark_TMark_T Posts: 1,981
    edited 2019-01-23 16:16
    David Betz wrote: »
    Dave Hein wrote: »
    Here's the output I get from the program using my
    I tried this:
    loadp2 -b 115200 -l 115200 cdemo.binary -t -v -p /dev/tty.usbserial-P2EEQXU -SINGLE
    
    and still no luck. Do I have to have the jumpers on the P2-Eval board set in a particular way? I haven't changed anything since Parallax shipped me the board. Has anyone gotten loadp2 to work on the Mac?

    Yes, but only by symlinking com1->/dev/tty..usbserial-P2EEQXU in .wine/dosdevices/ and
    using
    loadp2 -p COM1 -SINGLE -b115200 ....
    
    (via the command config in spin2gui)

    I don't think loadp2 can handle a unix device filename, it just bombed out with it.
  • David Betz wrote: »
    I'm still trying to figure out why my loads aren't working and it occurs to me that maybe it's a power problem. Is it okay to just power the P2-Eval board with the USB cable connected to the PC or do I need to also use a higher current USB power supply plugged into the other USB connector?
    I run the board with a USB cable plugged into a hub, but the PC should be able to power it. Some people have said they had to change the USB cable. I'm using the cable that came with my cell phone.
  • I use my phone charge cable, even though its very thin, and I measure about 0.25A with simple stuff loaded at 160MHz,
    though once I start multi-cog stuff that could become an issue.
  • David Betz wrote: »
    Dave Hein wrote: »
    Here's the output I get from the program using my Windows box.
    $ loadp2 -b 115200 -l 115200 cdemo.binary -t -v -p com4 -SINGLE
    Loading cdemo.binary - 3296 bytes
    cdemo.binary loaded
    ( Entering terminal mode.  Press Ctrl-] to exit. )
    fastspin C demo
    toggle 0
    toggle 1
    toggle 2
    toggle 3
    
    It also works if I specify -CHIP. However, it doesn't work if I don't specify a load mode. I'll have to look into that. I also noticed that if I specify a bad file name it still goes into the terminal mode.
    I tried this:
    loadp2 -b 115200 -l 115200 cdemo.binary -t -v -p /dev/tty.usbserial-P2EEQXU -SINGLE
    
    and still no luck. Do I have to have the jumpers on the P2-Eval board set in a particular way? I haven't changed anything since Parallax shipped me the board. Has anyone gotten loadp2 to work on the Mac?

    David,

    The following works on my MacBook Pro, running 10.14.2 (Mojave)... I think you need to use: 'cu' and not 'tty':
    loadp2 -p /dev/cu.usbserial-P2EEQXU -b 115200 -l 115200 -t -v -SINGLE cdemo.binary
    
    dgately
  • dgately wrote: »
    David Betz wrote: »
    Dave Hein wrote: »
    Here's the output I get from the program using my Windows box.
    $ loadp2 -b 115200 -l 115200 cdemo.binary -t -v -p com4 -SINGLE
    Loading cdemo.binary - 3296 bytes
    cdemo.binary loaded
    ( Entering terminal mode.  Press Ctrl-] to exit. )
    fastspin C demo
    toggle 0
    toggle 1
    toggle 2
    toggle 3
    
    It also works if I specify -CHIP. However, it doesn't work if I don't specify a load mode. I'll have to look into that. I also noticed that if I specify a bad file name it still goes into the terminal mode.
    I tried this:
    loadp2 -b 115200 -l 115200 cdemo.binary -t -v -p /dev/tty.usbserial-P2EEQXU -SINGLE
    
    and still no luck. Do I have to have the jumpers on the P2-Eval board set in a particular way? I haven't changed anything since Parallax shipped me the board. Has anyone gotten loadp2 to work on the Mac?

    David,

    The following works on my MacBook Pro, running 10.14.2 (Mojave)... I think you need to use: 'cu' and not 'tty':
    loadp2 -p /dev/cu.usbserial-P2EEQXU -b 115200 -l 115200 -t -v -SINGLE cdemo.binary
    
    dgately
    Thanks! I neglected to remember to use "cu." instead of "tty.". I'm sure that is my entire problem. I should have remembered that from my work with the P1 loaders. Duh...

  • David, have you tried just connecting a terminal program to the board and see if it responds? Just type "> Prop_Chk 0 0 0 0 ", and it should respond with it's version number. Or you could try the monitor or taqoz by changing some of the switches.
  • Mark_TMark_T Posts: 1,981
    edited 2019-01-23 16:32
    Hmm, that doesn't work for me, I'm on spin2gui 1.3.2. (And a relatively ancient 10.10.5 MacOS)

    Wine resets the dosdevices directory so I have a script to reset it after starting spin2gui under wine
  • So I've been digging around the threads for about 30m looking for why we need to use wine on the Mac at all.

    What am I missing?

    What's the issue with it not being native? Maybe it's something I can help with.

    (Probably not given the people working on this already but just on the off-chance, multiple eyeballs etc...)
Sign In or Register to comment.