It works! I was trying to use FlexProp to load the binary, but it must have been in P1 mode or something...
Loadp2 from the command line loads fast and blinks the LED.
I've probably bugged you all more than enough for one day...
But, I've got a million questions. One is what I can trim to cut the size down for posting on the web.
It's currently 643 MB zipped...
I arranged bin by size and then deleted everything below LLVM-C.dll and it still compiles.
Is that just because my code is crazy simple? Do we need all that stuff?
@Rayman said:
@n_ermosh Ok, that must be a different one that I have here: C:\opt\p2llvm\libp2\include
No, looks the same... But, I should include propeller.h, not propeller2.h, right?
propeller.h includes propeller2.h, I just left it as propeller.h out of habit
@iseries said:
I noticed that your code starts at $40 which is still in cog memory where flexprop starts at $400 which is the first memory location in hub memory.
Don't know if that helps.
Mike
Yeah, I place that startup code at 0x40 arbitrarily, I just wanted all that to be in less than 0x400 so it doesn't take up space from actual hub executable code (since code below 0x400 can't execute from the hub and must be loaded to hub ram).
@Rayman said:
@iseries said:
@Rayman ,
Sorry, that was for Nikita. We have memory issues with some debug code.
If you write a hello world program be aware that the default baud rate is 3,000,000.
Mike
Yikes, that's pushing the envelope... Is that easy to change?
Yeah, I can change it to 2M, but not slower-- it's a debug interface, it should run as fast as possible.
These examples are a bit outdated, some might still work though. This week I'll try to write up a getting started guide, but something like this for serial printing will work:
@Rayman said:
BTW: Would it be wrong to call all of this Clang instead of LLVM?
Appears this is a 2-part solution, but Clang is something I've heard of before, unlike LLVM....
clang is just the front end that compiles C/C++ to LLVM IR/LLVM data structures. the LLVM backend actually compiles that into P2 code. As a result, other languages that use LLVM as the backend (list Rust) can also be compiled for P2. Clang also provides a gcc-like interface to build a whole toolchain, which can invoke the linker to actually generate an executable, which is what we do here.
Maybe? I knew about llvm before clang Clang is considered a part of the LLVM infrastructure. But at the end of the day, the goal is merge this into upstream LLVM, so it's really a llvm project, not just a clang project, but a nice consequence is that we can compile C++ with it.
I also created this thread before the C++ forum group existed. I will probably create a separate thread soon anyway for posting actual "release" packages so that getting started is easier, and specifically reference clang there.
@iseries okay, so I got the large binary stuff worked out. Now, no debugging info is included by default, and if -mp2db is passed as an argument, only then will it link in the debugger code, and doesn't include a bunch of zero's to fill the debug space. So binaries are smaller and loads even faster.
I also added the intermediate step so that debug code doesn't intersect the clock setting addresses, but I haven't gotten patching to actually work. Disregard, patching works with loadp2, I was just doing it wrong. Just specify desired frequency with -f, optionally include clockmode. If baudrate isn't patched in, it will be set to 2Mbps, and _clkfreq to 24MHz, as that seems to be closer to the true clock speed, though it's probably not reliable enough to use for timed stuff like serial comms
This also involved a descent number of changes to libc, and garbage collection will not happen, unless -ffunction-sections -Wl,--gc-sections is specified.
The baud rate thing I don't think is used, not that I can remember.
If you pass in the clock rate on the command line it sets the clock rate and clock mode when it finishes loading the program as if you have no code in your program that sets those items. Then it jumps to zero. In the startup code I have it will grab that clock frequency number and compute the mode value and then set both those items.
Patch mode sets all of those items as the program is loaded.
The way elf files are loaded is that the program allocates a chunk of memory and then reads each section in and places it in the correct spot in memory. Then this chunk of memory is given to the boot loader program to copy into memory. This code is from the P1 days and with 32k it made sense.
Might need to create a new boot loader stub program that will load sections from the elf file thus avoiding those dead spaces. Not a big thing unless you are testing and constantly loading code.
@iseries Trying to figure out how to get the new small binary version going in Windows...
I tried repeating the git and build instructions, but getting the same result.
Do you need to update something before it filters down?
Are you managing llvm-project?
@iseries That was it! Elf file down to 34 kB now (was 521 kB).
No, Visual Studio Professional. I thought that's what you were using too at first.
Didn't know projects and solutions worked in Vidual Studio Code. Interesting...
@iseries Actually, for FlexSpin, Catalina, and GCC, I've used Visual Studio Professional in the "makefile" configuration.
That lets me run a build.bat file when the build command is given.
When the green play button is pushed, it does that and then loads the P2 automagically.
It's very convenient.
The "background compilation" feature is awesome and saves a lot of time. I think it might be the only editor that has this.
I used Visual Studio Professional most of the time to build stuff on the pc but not for p1 or p2 stuff. Then heard about Visual Studio Code and gave it a try.
It works great for c code with prompting of functions and code completion and errors before I compile. I was also able to figure out the compile and load options to work nicely with the product.
Visual Code open folders and loads in the configuration for that folder. I can then switch from flexprop, P2llvm, and use the different commands for each of them.
Never used the makefile or folder option with Visual Studio Professional. Maybe I have the same features as Code and I don't know it.
Made this Visual Studio Prof. solution with one hello_world project.
If you change the paths in build.bat and also in the project settings, it should build when build is selected from the menu.
It builds then runs when you click the green arrow "Local Windows Debugger".
Was concerned that the #include with <> would mess it up, but seems OK.
Seems it wants to use the Windows build includes when includes done that way and the local ones when "" is used.
But, seems that isn't an issue, at least for now...
Tried the "objects" example from github...
The four leds flash, maybe like they should, but only for around 4 seconds, then stop.
Is this just an old example, or did I build it wrong?
What is in the terminal window doesn't look right (or is it?):
( Entering terminal mode. Press Ctrl-] or Ctrl-Z to exit. )
cog ID is 1
cog ID is 1
cog ID is 1
cog ID is 1
cog ID is 1
cog ID is 1
cog ID is 1
cog ID is 0
.
Comments
@n_ermosh Ok, that must be a different one that I have here: C:\opt\p2llvm\libp2\include
No, looks the same... But, I should include propeller.h, not propeller2.h, right?
Ok, this compiles:
#include <propeller.h> int main() { for(;;) { drvnot(56); waitx(CLKFREQ); } return 0; }But, it doesn't run right... Looks to me like it is trying to load all 521 kB and going off the rails...
@Rayman ,
Do not rename the file. Loadp2 knows how to load elf files and should work out of the box as well as flexprop.
Mike
It works! I was trying to use FlexProp to load the binary, but it must have been in P1 mode or something...
Loadp2 from the command line loads fast and blinks the LED.
Thanks @n_ermosh and @iseries !
I noticed that your code starts at $40 which is still in cog memory where flexprop starts at $400 which is the first memory location in hub memory.
Don't know if that helps.
Mike
@iseries My code? Guess I don't know anything about how this works... How do I get it to start at $400 and run in hubexec mode?
@Rayman ,
Sorry, that was for Nikita. We have memory issues with some debug code.
If you write a hello world program be aware that the default baud rate is 3,000,000.
Mike
@Rayman ,
While the P2LLVM compiles programs nicely, be aware that the finally paint color or style of furniture has not been finalized.
Heck we don't even know if were having wine or beer.
Mike
Yikes, that's pushing the envelope... Is that easy to change?
I've probably bugged you all more than enough for one day...
But, I've got a million questions. One is what I can trim to cut the size down for posting on the web.
It's currently 643 MB zipped...
I arranged bin by size and then deleted everything below LLVM-C.dll and it still compiles.
Is that just because my code is crazy simple? Do we need all that stuff?
Is there a "Hello World" example?
doing #include "stdio.h" doesn't seem to work...
Including "printf.h" seems to get close, but can't find 'sys/va_list.h'
Ok, I see some examples on github: https://github.com/ne75/p2llvm/blob/master/examples/3_serial/serial.cpp
catching up here...
propeller.h includes propeller2.h, I just left it as propeller.h out of habit
Yeah, I place that startup code at 0x40 arbitrarily, I just wanted all that to be in less than 0x400 so it doesn't take up space from actual hub executable code (since code below 0x400 can't execute from the hub and must be loaded to hub ram).
Yeah, I can change it to 2M, but not slower-- it's a debug interface, it should run as fast as possible.
These examples are a bit outdated, some might still work though. This week I'll try to write up a getting started guide, but something like this for serial printing will work:
#include <stdio.h> #define P2_TARGET_MHZ 200 #include "propeller.h" #include "sys/p2es_clock.h" int main() { _clkset(_SETFREQ, _CLOCKFREQ); _uart_init(DBG_UART_RX_PIN, DBG_UART_TX_PIN, 3000000); printf("Hello\nWorld!\n"); return 0; }I reconfigure the clock so that it's reliable and not using the unstable internal RC clock
It works! Thanks.
Had to copy the libc folder over to C:\opt\p2llvm\llvm-project\build\Release to get stdio.h going.
There's a lib folder there that has a bunch of .lib files in it. Guessing we don't actually need that for running Clang, right?
BTW: Would it be wrong to call all of this Clang instead of LLVM?
Appears this is a 2-part solution, but Clang is something I've heard of before, unlike LLVM....
clang is just the front end that compiles C/C++ to LLVM IR/LLVM data structures. the LLVM backend actually compiles that into P2 code. As a result, other languages that use LLVM as the backend (list Rust) can also be compiled for P2. Clang also provides a gcc-like interface to build a whole toolchain, which can invoke the linker to actually generate an executable, which is what we do here.
@n_ermosh Sorta understand that, but since this is the C/C++ forum, seems like referencing Clang might make more sense and get more interest...
But, maybe I'm wrong and anybody that knows of Clang also knows of LLVM...
Maybe? I knew about llvm before clang
Clang is considered a part of the LLVM infrastructure. But at the end of the day, the goal is merge this into upstream LLVM, so it's really a llvm project, not just a clang project, but a nice consequence is that we can compile C++ with it.
I also created this thread before the C++ forum group existed. I will probably create a separate thread soon anyway for posting actual "release" packages so that getting started is easier, and specifically reference clang there.
I put my Windows build folder on my website for anybody who wants to try this without going through the build process:
https://www.rayslogic.com/Propeller2/Clang.htm
@iseries okay, so I got the large binary stuff worked out. Now, no debugging info is included by default, and if
-mp2dbis passed as an argument, only then will it link in the debugger code, and doesn't include a bunch of zero's to fill the debug space. So binaries are smaller and loads even faster.I also added the intermediate step so that debug code doesn't intersect the clock setting addresses, but I haven't gotten patching to actually work. Disregard, patching works with loadp2, I was just doing it wrong. Just specify desired frequency with -f, optionally include clockmode. If baudrate isn't patched in, it will be set to 2Mbps, and _clkfreq to 24MHz, as that seems to be closer to the true clock speed, though it's probably not reliable enough to use for timed stuff like serial comms
This also involved a descent number of changes to libc, and garbage collection will not happen, unless
-ffunction-sections -Wl,--gc-sectionsis specified.The baud rate thing I don't think is used, not that I can remember.
If you pass in the clock rate on the command line it sets the clock rate and clock mode when it finishes loading the program as if you have no code in your program that sets those items. Then it jumps to zero. In the startup code I have it will grab that clock frequency number and compute the mode value and then set both those items.
Patch mode sets all of those items as the program is loaded.
The way elf files are loaded is that the program allocates a chunk of memory and then reads each section in and places it in the correct spot in memory. Then this chunk of memory is given to the boot loader program to copy into memory. This code is from the P1 days and with 32k it made sense.
Might need to create a new boot loader stub program that will load sections from the elf file thus avoiding those dead spaces. Not a big thing unless you are testing and constantly loading code.
Mike
@iseries Trying to figure out how to get the new small binary version going in Windows...
I tried repeating the git and build instructions, but getting the same result.
Do you need to update something before it filters down?
Are you managing llvm-project?
@Rayman ,
It's in the make files that this happens.
He made a new p2.ld file that removed the debug information which causes most of the bloat. Did you copy that file from libp2 out.
Mike
@Rayman ,
Do you use Visual Studio Code to write your programs? I have build scripts for that environment.
Mike
@iseries That was it! Elf file down to 34 kB now (was 521 kB).
No, Visual Studio Professional. I thought that's what you were using too at first.
Didn't know projects and solutions worked in Vidual Studio Code. Interesting...
@iseries Actually, for FlexSpin, Catalina, and GCC, I've used Visual Studio Professional in the "makefile" configuration.
That lets me run a build.bat file when the build command is given.
When the green play button is pushed, it does that and then loads the P2 automagically.
It's very convenient.
The "background compilation" feature is awesome and saves a lot of time. I think it might be the only editor that has this.
@Rayman ,
I used Visual Studio Professional most of the time to build stuff on the pc but not for p1 or p2 stuff. Then heard about Visual Studio Code and gave it a try.
It works great for c code with prompting of functions and code completion and errors before I compile. I was also able to figure out the compile and load options to work nicely with the product.
Visual Code open folders and loads in the configuration for that folder. I can then switch from flexprop, P2llvm, and use the different commands for each of them.
Never used the makefile or folder option with Visual Studio Professional. Maybe I have the same features as Code and I don't know it.
Mike
Made this Visual Studio Prof. solution with one hello_world project.
If you change the paths in build.bat and also in the project settings, it should build when build is selected from the menu.
It builds then runs when you click the green arrow "Local Windows Debugger".
Was concerned that the #include with <> would mess it up, but seems OK.
Seems it wants to use the Windows build includes when includes done that way and the local ones when "" is used.
But, seems that isn't an issue, at least for now...
Tried the "objects" example from github...
The four leds flash, maybe like they should, but only for around 4 seconds, then stop.
Is this just an old example, or did I build it wrong?
What is in the terminal window doesn't look right (or is it?):
Likely outdated. Let me go through all the examples today and get them cleaned up and working again. I’ll update once that’s done