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.
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.
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.
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.
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:
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:
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.
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.
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.
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?
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!
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!
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.
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?
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.
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.
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.
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':
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.
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':
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.
Comments
I haven't tried to work out why -SINGLE wasn't the default. Actually, I haven't even tried using it.
EDIT: No that doesn't add up either. The Prop2 Doc says it can load up to 2 Mbps native.
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
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
Somebody suggested trying the -SINGLE option. The command line would be 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.
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 ...
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
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.
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!
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
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.
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
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.
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
though once I start multi-cog stuff that could become an issue.
David,
The following works on my MacBook Pro, running 10.14.2 (Mojave)... I think you need to use: 'cu' and not 'tty':
dgately
Wine resets the dosdevices directory so I have a script to reset it after starting spin2gui under wine
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...)