I just tried loading at 921600 on the Mac and it worked fine. However, it took a bit of time to switch the baud rate to 115200 for serial console I/O so I got garbage for the first few lines of my program output. I suppose I could avoid that by putting a delay at the start of my program. Anyway, 921600 works for loading.
That's great. It looks like I should change the default loader rate to 921600 for the Mac, and keep it at 2000000 for Linux and Windows. I'm away from home right now, but I'll do it on Tuesday.
I'm running SpinEdit on my Mac Mini under Wine and it works just fine (as an editor).
Still having issues loading large files...
... and wine is awesome. The only reason I popped up was because there was some discussion of issues with serial ports under wine earlier and, since I managed to port Gear to linux and someone suggested it was C# it was worth a look to see if it could be done without any modification (like I did with Gear).
*melts away into the background*
I did play with it in wine some too - it's pretty awesome...
We have too approaches to building code. One compiles P1 code and converts it to P2 code and the other just builds P2 code with limits.
I wanted to build a P2 loader in C# since I'm trying to stay away from the dark side. I looked at the code for the P2 loader just to see how it worked.
It's interesting that it first puts the P2 in hex mode and loads a small stub program that excepts the binary data and loads it into memory.
From there I started to play with different stub programs and have it now that I can switch in whatever stub loader I want to try today.
I now have it loading at 180Mhz at a baud rate of 2000000. Even with C# this works great.
I removed all the timing pieces that are memory mapped at the end of the stub program since I will only be loading a real P2 board. The only item it fills in is the length of the code to be loaded.
Next I'm going to see if I can use the serial that's in ROM along with sending back handshakes between each 1024 bytes that are loaded. Right now to load a blink program doesn't take much.
We have too approaches to building code. One compiles P1 code and converts it to P2 code and the other just builds P2 code with limits.
I wanted to build a P2 loader in C# since I'm trying to stay away from the dark side. I looked at the code for the P2 loader just to see how it worked.
It's interesting that it first puts the P2 in hex mode and loads a small stub program that excepts the binary data and loads it into memory.
From there I started to play with different stub programs and have it now that I can switch in whatever stub loader I want to try today.
I now have it loading at 180Mhz at a baud rate of 2000000. Even with C# this works great.
I removed all the timing pieces that are memory mapped at the end of the stub program since I will only be loading a real P2 board. The only item it fills in is the length of the code to be loaded.
Next I'm going to see if I can use the serial that's in ROM along with sending back handshakes between each 1024 bytes that are loaded. Right now to load a blink program doesn't take much.
Mike
What is the dark side? Also, why not use GCC?
Anyways C# is proprietary. That means I won't be able to program under Linux if your idea gets in front of GCC. Also, as the name of the thread suggests this is about PropGCC. If you want to rant about something, or build another compiler based on M$ products, please feel free to do so, but I suggest initiating another thread for that. C# for the Prop would be interesting for some users, but I wouldn't want it in the same package as PropGCC.
The dark side it Linux because the command lines are black. Come into the light.
There is no PropGCC for the P2. Just piece together tools and by the looks of it getting no where fast.
Mike
While there is no PropGCC for P2, there is fastspin which can compile Spin, PASM, BASIC, and soon C. It generates P2 native code without any translation from P1 code.
There is no PropGCC for the P2. Just piece together tools and by the looks of it getting no where fast.
I really think "going no where fast" is not accurate. p2gcc has made a lot of progress even in the past month, and Dave continually provides updates to it.
p2gcc and fastspin (and GCC, for that matter) are open source projects. Those who'd like to see faster progress on any or all of them are able to contribute...
There is no PropGCC for the P2. Just piece together tools and by the looks of it getting no where fast.
I really think "going no where fast" is not accurate. p2gcc has made a lot of progress even in the past month, and Dave continually provides updates to it.
p2gcc and fastspin (and GCC, for that matter) are open source projects. Those who'd like to see faster progress on any or all of them are able to contribute...
That is a good point. Dave is doing a wonderful job, even though the compiler is rough on the edges. If it was not p2gcc, I wouldn't be able to run intensive tests calculating prime numbers. That is something!
And even considering that long long ints and floats are not fully supported yet, it is possible to build a complete program with the tools available. You shouldn't disregard that.
There is no PropGCC for the P2. Just piece together tools and by the looks of it getting no where fast.
That's because the P2 has been hardware in flight. I'm not going to say that there's no point working on end-user tooling when everything is subject to change... but I'll say that it is a better use of time to work on it once it's in silicon (ie: stationary).
We got silicon ~3/4 weeks ago.
It's actually going staggeringly fast, the progress has been exceptional.
Well, if C# is now open source (cough), it wasn't a few years ago. Still, I think that we should not jump into that bandwagon for several reasons:
- C# license if not fitted with projects to be licensed under GNU GPL/LGPL;
- M$ can revoke the openness of C#;
- C is much better suited for micro-controller programming because of the simple, non OO approach that it offers.
My two cents. Also, lets stick to the plan, and lets continue adding support for the P2 with PropGCC.
P.S.: Personally, I hate C# because it took the OO paradigm too far. Why main() has to be a class?
- C is much better suited for micro-controller programming because of the simple, non OO approach that it offers.
I thought we were talking about a language to use to implement PC-based tools. While I'm not a fan of C# or .NET, it seems they would be adequate for that sort of thing. Was anyone actually talking about running C# code on the P2 itself?
- C is much better suited for micro-controller programming because of the simple, non OO approach that it offers.
I thought we were talking about a language to use to implement PC-based tools. While I'm not a fan of C# or .NET, it seems they would be adequate for that sort of thing. Was anyone actually talking about running C# code on the P2 itself?
No, but I am against that option either. As for using C# to build a tool, I don't wish to have to install a C# compiler while I can use GCC which is pretty much native under Linux.
The reason I used C# was to build a user interface that allowed me to select all the options and then pick the file to upload. This is a hole lot simpler than providing command line options.
On the other hand I would not be a fan of using C# as an end tool. But as for as educational tools, most schools are using a windows desktop or chrome.
The reason I used C# was to build a user interface that allowed me to select all the options and then pick the file to upload. This is a hole lot simpler than providing command line options.
On the other hand I would not be a fan of using C# as an end tool. But as for as educational tools, most schools are using a windows desktop or chrome.
Mike
You can do that very easily with Qt. I'm talking from experience, since I've developed myself some GUIs that would run commands behind the scenes.
How about we be cheerleaders for anyone who wishes to contribute to this community?
Sure - we may not use their tooling - but the wider the net we catch the more we win.
(says he who started implementing a P2 emulator in the erlang vm as a learning exercise)
Yes, I think we should encourage anyone who is contributing to the tools effort. Certainly, Eric Smith and Dave Hein have contributed a lot as has Chip with Pnut and Ray with SpinEdit and all of the others who are contributing. Thanks for your efforts!
2. Copied zip contents into ~/Applications/p2gcc folder I had created for it
3. Setup $PATH to include p2gcc/bin folder contents, and P2GCC_LIBDIR to p2gcc/lib folders, and also made propeller-elf-gcc etc available in the path (I had previously installed SimpleIDE). Eg.
4. ran ./build_macos from ~/Applications/p2gcc folder
5. modified a line in the file ~/Applications/p2gcc/bin/p2gcc to set the loader baud rate to 115200, and use the real CHIP not the FPGA. This was a key thing I had to figure out to get it to download without complaining about the baud rate.
loadstr="loadp2 -l 115200 -CHIP"
6. Also I found that if I didn't leave the terminal open after download the chip would reset immediate after download. I think this is related the whole DTR level thing.
p2gcc -p /dev/cu.usbserial-P23HPBP6 -r blink.c -t
After this I had a nice blinking LED program working doing a LED scanner with the on-board LEDs by modifying the included blink.c file.
Note: this program also toggles and drives SD/flash pins, so be careful if you use it. Make sure the SD card is out. It only drives one pin low at a time so I think it should be safe, famous last words, but be careful anyway as you won't want to trash your MISO pin on the on-board flash chip etc.
EDIT: Actually this P2 code would still drive the MISO pin high while the flash CS is low, so if the flash chip outputs a 0 when chip selected this is a bus clash and not good. You probably should disable the MISO pin driver too to be even safer.
rogloh, can you try running loadp2 without any parameters and look at what it prints out. It should show version 0.010 and a default loader baud rate of 921600. Is that what you see?
Can you try running the following commands to see which ones work, and which ones don't.
Is there a reason for not providing an already built binary for Mac?
I'm not a big Mac user, so forgive me if this is a dumb question...
I also see Eric provide a .exe for Windows, but not Mac or Linux.
Are there some dependencies which would cause a program to not run on a different Mac?
Is there a reason for not providing an already built binary for Mac?
I'm not a big Mac user, so forgive me if this is a dumb question...
I also see Eric provide a .exe for Windows, but not Mac or Linux.
Are there some dependencies which would cause a program to not run on a different Mac?
Is there a reason for not providing an already built binary for Mac?
I'm not a big Mac user, so forgive me if this is a dumb question...
I also see Eric provide a .exe for Windows, but not Mac or Linux.
Are there some dependencies which would cause a program to not run on a different Mac?
For myself, I build on a Linux system, and there's no cross compiler for Mac (or at least, I'm not aware of one), so that's why I don't post Mac binaries. I used to post Linux fastspin binaries, but I think there was maybe one download in 6 months -- most Linux users just build it themselves from source.
I don't have a Mac, so I can't do a Mac build. I have a Linux system, but I've never posted binaries for Linux. Once in a while I do post Windows binaries along with the source in this thread, but that doesn't happen very often. The best place to get binaries is from David Zemon's site.
Comments
That makes a lot of sense, and unfortunately - MFC is Windows only.
Don't we all :-D
Thanks for confirming that - I was hoping for an easy button - no such luck!
Thanks,
Red
Still having issues loading large files...
... and wine is awesome. The only reason I popped up was because there was some discussion of issues with serial ports under wine earlier and, since I managed to port Gear to linux and someone suggested it was C# it was worth a look to see if it could be done without any modification (like I did with Gear).
*melts away into the background*
I did play with it in wine some too - it's pretty awesome...
We have too approaches to building code. One compiles P1 code and converts it to P2 code and the other just builds P2 code with limits.
I wanted to build a P2 loader in C# since I'm trying to stay away from the dark side. I looked at the code for the P2 loader just to see how it worked.
It's interesting that it first puts the P2 in hex mode and loads a small stub program that excepts the binary data and loads it into memory.
From there I started to play with different stub programs and have it now that I can switch in whatever stub loader I want to try today.
I now have it loading at 180Mhz at a baud rate of 2000000. Even with C# this works great.
I removed all the timing pieces that are memory mapped at the end of the stub program since I will only be loading a real P2 board. The only item it fills in is the length of the code to be loaded.
Next I'm going to see if I can use the serial that's in ROM along with sending back handshakes between each 1024 bytes that are loaded. Right now to load a blink program doesn't take much.
Mike
Anyways C# is proprietary. That means I won't be able to program under Linux if your idea gets in front of GCC. Also, as the name of the thread suggests this is about PropGCC. If you want to rant about something, or build another compiler based on M$ products, please feel free to do so, but I suggest initiating another thread for that. C# for the Prop would be interesting for some users, but I wouldn't want it in the same package as PropGCC.
Kind regards, Samuel Lourenço
There is no PropGCC for the P2. Just piece together tools and by the looks of it getting no where fast.
Mike
That way I can take my SimpleIDE C programs and compile them. Then run the conversion to P2 and load them.
Some functions are still not there though.
Mike
I really think "going no where fast" is not accurate. p2gcc has made a lot of progress even in the past month, and Dave continually provides updates to it.
p2gcc and fastspin (and GCC, for that matter) are open source projects. Those who'd like to see faster progress on any or all of them are able to contribute...
Mike
That is a good point. Dave is doing a wonderful job, even though the compiler is rough on the edges. If it was not p2gcc, I wouldn't be able to run intensive tests calculating prime numbers. That is something!
And even considering that long long ints and floats are not fully supported yet, it is possible to build a complete program with the tools available. You shouldn't disregard that.
Kind regards, Samuel Lourenço
https://github.com/dotnet/csharplang
C# is Open Source.
https://github.com/dotnet/core
.net core is Open Source
Sure you can. Not only can you develop under Linux, but any executables you build are platform independent (just like java).
Lastly...
That's because the P2 has been hardware in flight. I'm not going to say that there's no point working on end-user tooling when everything is subject to change... but I'll say that it is a better use of time to work on it once it's in silicon (ie: stationary).
We got silicon ~3/4 weeks ago.
It's actually going staggeringly fast, the progress has been exceptional.
Kind Regards,
Red
- C# license if not fitted with projects to be licensed under GNU GPL/LGPL;
- M$ can revoke the openness of C#;
- C is much better suited for micro-controller programming because of the simple, non OO approach that it offers.
My two cents. Also, lets stick to the plan, and lets continue adding support for the P2 with PropGCC.
P.S.: Personally, I hate C# because it took the OO paradigm too far. Why main() has to be a class?
Kind regards, Samuel Lourenço
Kind regards, Samuel Lourenço
On the other hand I would not be a fan of using C# as an end tool. But as for as educational tools, most schools are using a windows desktop or chrome.
Mike
How about we be cheerleaders for anyone who wishes to contribute to this community?
Sure - we may not use their tooling - but the wider the net we catch the more we win.
(says he who started implementing a P2 emulator in the erlang vm as a learning exercise)
Kind regards, Samuel Lourenço
I can step through and when it hits a problem it stops and I can see all the variables.
I sometimes build test code there so I can debug it and then move it to the desired platform.
Mike
Needed several things first before things worked...(this is from memory)
1. downloaded the zip file from Github source here
https://github.com/davehein/p2gcc
2. Copied zip contents into ~/Applications/p2gcc folder I had created for it
3. Setup $PATH to include p2gcc/bin folder contents, and P2GCC_LIBDIR to p2gcc/lib folders, and also made propeller-elf-gcc etc available in the path (I had previously installed SimpleIDE). Eg.
export PATH=$PATH:~/Applications/p2gcc/bin
export P2GCC_LIBDIR=~/Applications/p2gcc/lib
export PATH=$PATH:/Applications/SimpleIDE.app/Contents/propeller-gcc/bin
4. ran ./build_macos from ~/Applications/p2gcc folder
5. modified a line in the file ~/Applications/p2gcc/bin/p2gcc to set the loader baud rate to 115200, and use the real CHIP not the FPGA. This was a key thing I had to figure out to get it to download without complaining about the baud rate.
loadstr="loadp2 -l 115200 -CHIP"
6. Also I found that if I didn't leave the terminal open after download the chip would reset immediate after download. I think this is related the whole DTR level thing.
p2gcc -p /dev/cu.usbserial-P23HPBP6 -r blink.c -t
After this I had a nice blinking LED program working doing a LED scanner with the on-board LEDs by modifying the included blink.c file.
Note: this program also toggles and drives SD/flash pins, so be careful if you use it. Make sure the SD card is out. It only drives one pin low at a time so I think it should be safe, famous last words, but be careful anyway as you won't want to trash your MISO pin on the on-board flash chip etc.
EDIT: Actually this P2 code would still drive the MISO pin high while the flash CS is low, so if the flash chip outputs a 0 when chip selected this is a bus clash and not good. You probably should disable the MISO pin driver too to be even safer.
#include <propeller.h> unsigned int _clkfreq = 80000000; int main(void) { int32_t Index; OUTB |= 0x3f000000; DIRB |= 0x3f000000; while (1) { for(Index = 24; Index <= 29; Index++) { OUTB &= ~(1 << Index); waitcnt(((CLKFREQ / 50) + CNT)); OUTB |= ((1 << Index)); waitcnt(((CLKFREQ / 50) + CNT)); } for(Index = 29; Index >= 24; Index--) { OUTB &= ~(1 << Index); waitcnt(((CLKFREQ / 50) + CNT)); OUTB |= ((1 << Index)); waitcnt(((CLKFREQ / 50) + CNT)); } } }Can you try running the following commands to see which ones work, and which ones don't.
loadp2 a.out
loadp2 -t a.out
loadp2 -t -l 921600 a.out
loadp2 -t -l 921600 a.out -SINGLE
loadp2 -t -l 921600 a.out -CHIP
loadp2 -t a.out -SINGLE
loadp2 -t a.out -CHIP
I'm not a big Mac user, so forgive me if this is a dumb question...
I also see Eric provide a .exe for Windows, but not Mac or Linux.
Are there some dependencies which would cause a program to not run on a different Mac?
You can get Mac binaries for various different tools, including Spin2Gui and p2gcc, from my server: http://david.zemon.name:8111?guest=1
For myself, I build on a Linux system, and there's no cross compiler for Mac (or at least, I'm not aware of one), so that's why I don't post Mac binaries. I used to post Linux fastspin binaries, but I think there was maybe one download in 6 months -- most Linux users just build it themselves from source.
Which gui are you running this in?? I tried spin2gui but no math.h, library. Can you help?