OK, thank you for your prompt response! Just to confirm: you like CLion as a primary choice of IDE, correct? My Debian box is a brand new install so I'm trying to keep things somewhat organized as I become more familiar with the Deb environment.
OK, thank you for your prompt response! Just to confirm: you like CLion as a primary choice of IDE, correct? My Debian box is a brand new install so I'm trying to keep things somewhat organized as I become more familiar with the Deb environment.
In case I haven't shown enough enthusiasm elsewhere.... ABSOLUTELY! Let's put it this way, if JetBrains makes a tool to solve a problem, and you need a tool to solve that problem, there's a STRONG possibility that JetBrains' tool is the best one in the world. It's a bold claim, I know, but I truly believe it. Are there tiny circumstances where Tool A might be better than a JetBrains tool? Sure. There are niche places where others can be better. But overall, I've yet to find any company that can beat JetBrains at their own game... and finally, JetBrains is playing the C/C++ game
And no, I don't work for JetBrains. I'm just an user of many of their products (IDEA, CLion, PyCharm, WebStorm) and love them all. I've yet to find any tool that can compete in the Java, C/C++, Python, or web sphere (and there are lots more too). http://www.jetbrains.com/products.html
For those not willing to deal with instabilities and minor bugs, do choose something that isn't still in beta :P
Eclipse and Code::Blocks are well-known IDEs supported by CMake. Someday, CLion will come out of EAP (beta), but for the moment, you've gotta be on your toes to use it. It does still have bugs and missing features (for instance, one of my big annoyances is that a multiline comment gets formatted incorrectly when you auto-format your file - so all of my Doxygen documentation gets screwed up).
Note worthy changes were just made and have been merged with the release-2.0 branch:
I've moved all UART classes into their own folder (PropWare/PropWare/uart). I also broke out every class into it's own file since uart.h was getting much too long. The base class for UART is now a proper interface with pure virtual methods. And, finally, a new interface was created for Duplex UART classes.
User source code should require minimal changes. I believe all that is necessary is that your "#include" lines change to reflect the moved and renamed files.
All changes can be seen in the documentation. If you're interested, you might start with PropWare::UART and then look at its inheritance graph for further reading.
This will be fun... I'm writing my own unit testing framework now. I looked into Unity as SRLM is using with libpropeller, but it does not play nicely with CMake and has a ruby dependency which would wreak havoc on Windows users. Google's framework requires numerous components not available in PropGCC. Other frameworks are in similar boats - either pulling in too much bloat or not working with CMake and/or C++.
If anyone has suggestions, throw them at me. Otherwise, I'll be in my cave.
--Update--
To implement all the features I wanted was going to be way more work than I expected, so I'm calling the framework done (or at least alpha done) with the following functional test:
#include "../PropWareTests.h"
TEST(CheckAssert) {
ASSERT(true);
return true;
}
TEST(CheckFail) {
FAIL("This test was supposed to fail :)");
}
TEST(CheckAssertTrue) {
ASSERT_TRUE(true);
return true;
}
TEST(CheckAssertEq) {
int x = 3;
int y = 4;
int expected = 7;
int actual = x + y;
ASSERT_EQ(expected, actual);
return true;
}
TEST(CheckAssertEq_ExpectFailure) {
int x = 3;
int y = 42; // Oops! That'd be a typo wouldn't it? :)
int expected = 7;
int actual = x + y;
ASSERT_EQ(expected, actual);
return true;
}
TEST(CheckAssertNeq) {
int x = 3;
int y = 42; // Oops! That'd be a typo wouldn't it? :)
int expected = 7;
int actual = x + y;
ASSERT_NEQ(expected, actual);
return true;
}
TEST(CheckAssertNeq_ExpectFailure) {
int x = 3;
int y = 4;
int expected = 7;
int actual = x + y;
ASSERT_NEQ(expected, actual);
return true;
}
int main () {
RUN_TEST(CheckAssert);
EXPECT_FAIL(CheckFail);
RUN_TEST(CheckAssertTrue);
RUN_TEST(CheckAssertEq);
EXPECT_FAIL(CheckAssertEq_ExpectFailure);
RUN_TEST(CheckAssertNeq);
EXPECT_FAIL(CheckAssertNeq_ExpectFailure);
return 0;
}
That's everything possible. Simple... combining that with a Python script to scrape the output and check for "FAILURE" messages should provide a decent way to unit test any packages I want. Tomorrow starts the actual testing.
Well... I may not have posted here in quite some time, but that doesn't mean PropWare has been anywhere near stagnant! Printing to the terminal has completely changed - but all for the better! To write a basic "Hello, world!" program using PropWare is quite simple now:
int main () {
pwOut.printf("Hello, world!" CRLF);
return 0;
}
Many other changes were also made. I've tagged another beta release (#5 this time). We're getting closer to a real v2.0 release... but I still need to tackle the SD card re-write, Spin files and hopefully synchronous printing. I hope anyone curious will go check out the latest release from GitHub (binaries available) or checkout/update the source code!
Woohoo! Another big step for PropGCC! Users of PropWare's SynchronousPrinter class now have easy access to synchronous printing from any and all cogs. This is great for debug logging from multiple cogs without worry about contention over the serial bus. I'm sure you can think of even more uses though
Also included in the latest commit of release-2.0-nightly is a functional Scanner class. Receiving input from the user is now wonderfully simple.
I am now starting to use the issue track on github. If anyone finds problems with code, documentation, the website, or requests for new/improved objects, please let me know. You can either create the new issue yourself or contact me and I'll add the issue in
Oh I'm pretty happy with this! I've created a nice, easy-to-use Runnable class. Here's all the code it takes to have two cogs printing hello:
#include <PropWare/PropWare.h>
#include <PropWare/runnable.h>
#include <PropWare/printer/synchronousprinter.h>
class TalkingThread : public PropWare::Runnable {
public:
TalkingThread (const uint32_t *stack, const size_t stackSizeInBytes)
: Runnable(stack, stackSizeInBytes) {}
void run () {
while (1) {
pwSyncOut.printf("Hello from cog %u (0x%08X)! %u" CRLF, cogid(), (unsigned int) this, CNT);
waitcnt(250 * MILLISECOND + CNT);
}
}
};
int main (int argc, char *argv[]) {
uint32_t stack[16];
TalkingThread talkingThread(stack, sizeof(stack));
int8_t cog = PropWare::Runnable::invoke(talkingThread);
pwSyncOut.printf("Talking thread (0x%08X) started in cog %d" CRLF, (unsigned int) &talkingThread, cog);
while (1) {
pwSyncOut.printf("Hello from cog %u! %u" CRLF, cogid(), CNT);
waitcnt(250 * MILLISECOND + CNT);
}
}
I think this is much more user-friendly than any of the functions provided natively in PropGCC or through Simple.
The above code shows off both the SynchronousPrinter and the new Runnable class. The demo in the PropWare sources also starts up two more cogs blinking LEDs. I'm thinking about implementing something like Java's Executors.newFixedThreadPool, but am still working out the how aspect.
Some day I gotta get back to that darn SD card and all its brokenness
PropWare completely revamped filesystem classes are coming right along! Last night I found a number of small but critical bugs and fixed them. My FAT32 filesystem now mounts again, so the rest should go pretty smooth I hope (the logic is already there, just needs refactoring)! For anyone that has been waiting on the SD/FAT32 objects, thank you for your patience! We're very close now.
PropWare completely revamped filesystem classes are coming right along! Last night I found a number of small but critical bugs and fixed them. My FAT32 filesystem now mounts again, so the rest should go pretty smooth I hope (the logic is already there, just needs refactoring)! For anyone that has been waiting on the SD/FAT32 objects, thank you for your patience! We're very close now.
Are you using the dosfs code from PropGCC in PropWare? If not, have you found better FAT32 code? Can we adopt it for PropGCC?
Are you using the dosfs code from PropGCC in PropWare? If not, have you found better FAT32 code? Can we adopt it for PropGCC?
I wrote my own code from scratch - it started as a class project (that was one tough class) for the 8051, but I decided to write it on the Propeller first where I had more power and memory and then ported each step of the project to the 8051 along the way.
It could be used in PropGCC - absolutely. I can't promise it's any better - I haven't done any comparison what-so-ever. It's a very different approach. Since it's currently C++, it would take some tweaking to convert to C.
I'm very excited to get this done though. The low-level code needs more work in the future: one easy and key feature that needs to be done is a block-read/write function in the SPI driver. At the moment, all reads and writes are done one byte at a time . I'll get to it, but I want to the finish the rest of the high-level stuff first. konimaru made the necessary changes to SPI driver to get 4 MHz burst read/write working though! That makes me very happy.
This system looks great, and I'd love to run it! However, I just can't get it to install properly on any platform I try.
So far, I've failed on Windows 8.1, Windows 10 (understandable?), and Ubuntu Linux 14.04, all 64-bit. I've tried the source and binary distributions.
The errors revolve around the compiler test failing (propeller-elf-gcc "broken"), and git not being able to retrieve libpropeller. I've followed the install instructions verbatim, and made sure git was installed (although not listed as a dependency, I found it's required).
This system looks great, and I'd love to run it! However, I just can't get it to install properly on any platform I try.
So far, I've failed on Windows 8.1, Windows 10 (understandable?), and Ubuntu Linux 14.04, all 64-bit. I've tried the source and binary distributions.
The errors revolve around the compiler test failing (propeller-elf-gcc "broken"), and git not being able to retrieve libpropeller. I've followed the install instructions verbatim, and made sure git was installed (although not listed as a dependency, I found it's required).
I can post error messages if that would help...
Any thoughts?
- Earl
Thanks for giving it a try! I'd love to help you work through the issues and fix whatever is broken on my end. Let's move the debugging to emails though so as to not clutter this thread (whenever we find the root of the problem we can post it back here for future googlers)
Well, we've got the problem solved and it was indeed an issue with the install script. The zlib1g:i386 dependency is required by 64-bit Ubuntu machines and is not installed by default. I will be rectifying this issue soon so hopefully it won't affect anyone else.
For archival purposes, here's the tail end of the install script which contains the error message (look for a reference to libz.so.1)
cmake -G Unix Makefiles ~/PropWare-release-2.0
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
-- The ASM compiler identification is GNU
-- Found assembler: ~/propgcc/bin/propeller-elf-gcc
-- The COGC compiler identification is unknown
-- The COGCXX compiler identification is unknown
-- The ECOGC compiler identification is unknown
-- The ECOGCXX compiler identification is unknown
-- LOADED: Generic-gcc-Propeller.cmake
-- Check for working C compiler: ~/propgcc/bin/propeller-elf-gcc
-- Check for working C compiler: ~/propgcc/bin/propeller-elf-gcc -- broken
CMake Error at ~/cmake-3.0.2-Linux-i386/share/cmake-3.0/Modules/CMakeTestCCompiler.cmake:61 (message):
The C compiler "~/propgcc/bin/propeller-elf-gcc" is not able to
compile a simple test program.
It fails with the following output:
Change Dir: ~/PropWare-release-2.0/bin/CMakeFiles/CMakeTmp
Run Build Command:"/usr/bin/make" "cmTryCompileExec1823009790/fast"
/usr/bin/make -f CMakeFiles/cmTryCompileExec1823009790.dir/build.make
CMakeFiles/cmTryCompileExec1823009790.dir/build
make[1]: Entering directory
`~/PropWare-release-2.0/bin/CMakeFiles/CMakeTmp'
~/cmake-3.0.2-Linux-i386/bin/cmake -E cmake_progress_report
~/PropWare-release-2.0/bin/CMakeFiles/CMakeTmp/CMakeFiles 1
Building C object
CMakeFiles/cmTryCompileExec1823009790.dir/testCCompiler.c.obj
~/propgcc/bin/propeller-elf-gcc -o
CMakeFiles/cmTryCompileExec1823009790.dir/testCCompiler.c.obj -c
~/PropWare-release-2.0/bin/CMakeFiles/CMakeTmp/testCCompiler.c
~/propgcc/bin/../lib/gcc/propeller-elf/4.6.1/../../../../propeller-elf/bin/as:
error while loading shared libraries: libz.so.1: cannot open shared object
file: No such file or directory
make[1]: ***
[CMakeFiles/cmTryCompileExec1823009790.dir/testCCompiler.c.obj] Error 1
make[1]: Leaving directory
`~/PropWare-release-2.0/bin/CMakeFiles/CMakeTmp'
make: *** [cmTryCompileExec1823009790/fast] Error 2
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:8 (project)
-- Configuring incomplete, errors occurred!
See also "~/PropWare-release-2.0/bin/CMakeFiles/CMakeOutput.log".
See also "~/PropWare-release-2.0/bin/CMakeFiles/CMakeError.log".
Traceback (most recent call last):
File "INSTALL.py", line 562, in <module>
installer.install()
File "INSTALL.py", line 109, in install
self._build_binaries()
File "INSTALL.py", line 167, in _build_binaries
raise CMakeFailedException()
__main__.CMakeFailedException
Work continues on my SD implementation (known as the PropWare::FatFS class). It's painfully slow, but I'm making progress. My issue list is piling up quite high while I work on this. It's nice to have some real organization though - never had proper task management before.
In the meantime, I've found a GREAT benefit to PropWare! If you're using PropWare's classes for serial communication (such as `pwOut.printf("...")`) then you can increment the baud rate in your propeller-load configure script which will yield significantly faster transfer of your program as well as faster comms during runtime! The default configure script for the quickstart looks like this:
And that's it! I'm thrilled with this, and rather surprised I didn't think to do it earlier. PropWare's serial classes already get their default baud rate from propeller-load, so any value you set in this script will be picked up during flashing - no need for any code changes!
NOTE: This will not work with most other serial implementations, including the standard Parallax utilities (printf, cout, print, printi, __simple_printf, etc).
460,800 was the max I was able to reach. 576,000 was so fast that, it seems the Propeller couldn't reset itself before communication started and I'd get "error: load failed" every other time.
Firstly: loading/running/debugging with the baud rate set to 460,800 is amazing. You should all try it.
Second: PropWare can finally read files from an SD card again! This was a huge effort to refactor my old SD class (which was 2,600 lines of code), but I'm nearly done! What used to be a single class - PropWare::SD - is now many classes. The basics looks like this:
I know - that's a lot more lines of code than the Parallax method - but this gets us a few things:
1) Object-oriented file handling
2) Each file can have its own buffer or share the common buffer for the filesystem (default). This is selectable on a per-file basis at runtime.
3) The class hierarchy was built with the goal of being extendable. Using PropWare as a base, the Propeller community could soon be reading from floppy disks. Or CDs. Or hard drives. Or a different file system (like ext4 or ntfs.... although I have no idea if we have RAM space for that).
PropWare's system seems to use about 1kB more space in LMM than Parallax's fopen and fgetc. Personally... I'm willing to live with this. I'll see if there are optimization that can be made, but this is a great starting point.
JetBrains TeamCity has been turned on and is now auto-deploying new binary distributions and new documentation pages every time I commit. No more out-of-date binaries or documentation.
For reference though, the website (http://david.zemon.name/PropWare) is always pointing to the nightly branch, so there's a chance that it might look different from what you have locally.
I've also started using CMake's CPack for creating the zips instead of my own Python script. A minor implementation detail, but very nice for me none-the-less
PropWare's documentation pages have just undergone a major reorganization. Content is still largely the same but is now ordered in a logical fashion and hopefully reads like a user manual instead of random pages strewn about. Putting the pages in order has revealed some backwards logic on my part - chapter 2 referencing content in chapter 4, for instance - so I will get that fixed soon.
This reorg should make getting started for new users much easier and more clear.
Isn't TeamCity cool? I wasn't sure about GitHub support.
I still run some older version, somewhere in Germany near the coast. Need to update it. Them code-duplicate runners are awfully painful. They stuck your nose right into it like lint and jslint do.
TeamCity is live, PropGCC and PropWare are both building automagically and....
....
...
PropWare works on a raspberry pi! I did have to compile CMake from source though. I have not uploaded the binary anywhere and don't have immediate plans to. Compiling is quite straight forward though:
# Download & extract cmake
sudo apt-get install cmake make g++
cd <cmake directory>
cmake .
make
the cmake command and make will both take a long time, but they worked first try for me. If you're running a pi 2, run "make -j3" instead of "make".
Today was a great day! I tried writing a WS2812b routine but that failed miserably. Way more complex than I expected. I'll get it eventually, but not today.
However, UART routines just sped up significantly. Max (transmit) speed is now 4.4 MBaud and an average rate of 2.7 Mbps can be held at that baud when invoked via the send_array or puts routines! With this, PropWare finally ranks right up there with other high-speed Propeller serial comms... and it's still just as configurable as before! And small! The most up-to-date specs for speed can always be found here.
Today was a great day! I tried writing a WS2812b routine but that failed miserably. Way more complex than I expected. I'll get it eventually, but not today.
I just used JonnyMac's PASM code and wrote a C++ interface to it. I can send it to you if you'd like.
I just used JonnyMac's PASM code and wrote a C++ interface to it. I can send it to you if you'd like.
That might provide a nice interim solution. I'm hoping to provide a solution that doesn't require use of a second cog though (now that I'm really getting the hang of inline assembly).
When I first picked it up I expected a simple serial routine using standard UART protocol or maybe I2C... but this thing is just too weird lol
That might provide a nice interim solution. I'm hoping to provide a solution that doesn't require use of a second cog though (now that I'm really getting the hang of inline assembly).
When I first picked it up I expected a simple serial routine using standard UART protocol or maybe I2C... but this thing is just too weird lol
I think it's interesting that one of the big strengths of the Propeller is supposed to be multiple COGs and so-called soft peripherals but people are often trying to figure out how to do things in a single COG like UARTs and now this WS2812 code. Maybe we should all just switch to ARM cores where everything is always done on the same core. :-)
I think it's interesting that one of the big strengths of the Propeller is supposed to be multiple COGs and so-called soft peripherals but people are often trying to figure out how to do things in a single COG like UARTs and now this WS2812 code. Maybe we should all just switch to ARM cores where everything is always done on the same core. :-)
You bring up a good point. Write-only devices are actually perfect examples of where a dedicated cog makes perfect sense - send the data to a buffer and then let it do the work on its own time. I think I'll do that. I'm used to things like ADCs and SD cards where you end up doing a blocking call anyway because you're waiting to read data back in. In those cases, dedicated cog is just a waste of hardware! Interesting that my ADC and SD routines both rely on SPI (dedicated cog) and my UART routines are inline assembly... I seem to have gotten things a tad backwards
Comments
In case I haven't shown enough enthusiasm elsewhere.... ABSOLUTELY! Let's put it this way, if JetBrains makes a tool to solve a problem, and you need a tool to solve that problem, there's a STRONG possibility that JetBrains' tool is the best one in the world. It's a bold claim, I know, but I truly believe it. Are there tiny circumstances where Tool A might be better than a JetBrains tool? Sure. There are niche places where others can be better. But overall, I've yet to find any company that can beat JetBrains at their own game... and finally, JetBrains is playing the C/C++ game
And no, I don't work for JetBrains. I'm just an user of many of their products (IDEA, CLion, PyCharm, WebStorm) and love them all. I've yet to find any tool that can compete in the Java, C/C++, Python, or web sphere (and there are lots more too).
http://www.jetbrains.com/products.html
Eclipse and Code::Blocks are well-known IDEs supported by CMake. Someday, CLion will come out of EAP (beta), but for the moment, you've gotta be on your toes to use it. It does still have bugs and missing features (for instance, one of my big annoyances is that a multiline comment gets formatted incorrectly when you auto-format your file - so all of my Doxygen documentation gets screwed up).
I've moved all UART classes into their own folder (PropWare/PropWare/uart). I also broke out every class into it's own file since uart.h was getting much too long. The base class for UART is now a proper interface with pure virtual methods. And, finally, a new interface was created for Duplex UART classes.
User source code should require minimal changes. I believe all that is necessary is that your "#include" lines change to reflect the moved and renamed files.
All changes can be seen in the documentation. If you're interested, you might start with PropWare::UART and then look at its inheritance graph for further reading.
If anyone has suggestions, throw them at me. Otherwise, I'll be in my cave.
--Update--
To implement all the features I wanted was going to be way more work than I expected, so I'm calling the framework done (or at least alpha done) with the following functional test:
#include "../PropWareTests.h" TEST(CheckAssert) { ASSERT(true); return true; } TEST(CheckFail) { FAIL("This test was supposed to fail :)"); } TEST(CheckAssertTrue) { ASSERT_TRUE(true); return true; } TEST(CheckAssertEq) { int x = 3; int y = 4; int expected = 7; int actual = x + y; ASSERT_EQ(expected, actual); return true; } TEST(CheckAssertEq_ExpectFailure) { int x = 3; int y = 42; // Oops! That'd be a typo wouldn't it? :) int expected = 7; int actual = x + y; ASSERT_EQ(expected, actual); return true; } TEST(CheckAssertNeq) { int x = 3; int y = 42; // Oops! That'd be a typo wouldn't it? :) int expected = 7; int actual = x + y; ASSERT_NEQ(expected, actual); return true; } TEST(CheckAssertNeq_ExpectFailure) { int x = 3; int y = 4; int expected = 7; int actual = x + y; ASSERT_NEQ(expected, actual); return true; } int main () { RUN_TEST(CheckAssert); EXPECT_FAIL(CheckFail); RUN_TEST(CheckAssertTrue); RUN_TEST(CheckAssertEq); EXPECT_FAIL(CheckAssertEq_ExpectFailure); RUN_TEST(CheckAssertNeq); EXPECT_FAIL(CheckAssertNeq_ExpectFailure); return 0; }This produces the output:
That's everything possible. Simple... combining that with a Python script to scrape the output and check for "FAILURE" messages should provide a decent way to unit test any packages I want. Tomorrow starts the actual testing.
Many other changes were also made. I've tagged another beta release (#5 this time). We're getting closer to a real v2.0 release... but I still need to tackle the SD card re-write, Spin files and hopefully synchronous printing. I hope anyone curious will go check out the latest release from GitHub (binaries available) or checkout/update the source code!
Cheers,
David
Also included in the latest commit of release-2.0-nightly is a functional Scanner class. Receiving input from the user is now wonderfully simple.
https://github.com/DavidZemon/PropWare/issues
#include <PropWare/PropWare.h> #include <PropWare/runnable.h> #include <PropWare/printer/synchronousprinter.h> class TalkingThread : public PropWare::Runnable { public: TalkingThread (const uint32_t *stack, const size_t stackSizeInBytes) : Runnable(stack, stackSizeInBytes) {} void run () { while (1) { pwSyncOut.printf("Hello from cog %u (0x%08X)! %u" CRLF, cogid(), (unsigned int) this, CNT); waitcnt(250 * MILLISECOND + CNT); } } }; int main (int argc, char *argv[]) { uint32_t stack[16]; TalkingThread talkingThread(stack, sizeof(stack)); int8_t cog = PropWare::Runnable::invoke(talkingThread); pwSyncOut.printf("Talking thread (0x%08X) started in cog %d" CRLF, (unsigned int) &talkingThread, cog); while (1) { pwSyncOut.printf("Hello from cog %u! %u" CRLF, cogid(), CNT); waitcnt(250 * MILLISECOND + CNT); } }I think this is much more user-friendly than any of the functions provided natively in PropGCC or through Simple.
The above code shows off both the SynchronousPrinter and the new Runnable class. The demo in the PropWare sources also starts up two more cogs blinking LEDs. I'm thinking about implementing something like Java's Executors.newFixedThreadPool, but am still working out the how aspect.
Some day I gotta get back to that darn SD card and all its brokenness
I wrote my own code from scratch - it started as a class project (that was one tough class) for the 8051, but I decided to write it on the Propeller first where I had more power and memory and then ported each step of the project to the 8051 along the way.
It could be used in PropGCC - absolutely. I can't promise it's any better - I haven't done any comparison what-so-ever. It's a very different approach. Since it's currently C++, it would take some tweaking to convert to C.
I'm very excited to get this done though. The low-level code needs more work in the future: one easy and key feature that needs to be done is a block-read/write function in the SPI driver. At the moment, all reads and writes are done one byte at a time
So far, I've failed on Windows 8.1, Windows 10 (understandable?), and Ubuntu Linux 14.04, all 64-bit. I've tried the source and binary distributions.
The errors revolve around the compiler test failing (propeller-elf-gcc "broken"), and git not being able to retrieve libpropeller. I've followed the install instructions verbatim, and made sure git was installed (although not listed as a dependency, I found it's required).
I can post error messages if that would help...
Any thoughts?
- Earl
Thanks for giving it a try! I'd love to help you work through the issues and fix whatever is broken on my end. Let's move the debugging to emails though so as to not clutter this thread (whenever we find the root of the problem we can post it back here for future googlers)
david@zemon.name
Cheers,
David
I've sent an e-mail just now, with the terminal log of an install attempt on a freshly installed and updated Ubuntu 14.04 64-bit system.
Best Regards,
- Earl
For archival purposes, here's the tail end of the install script which contains the error message (look for a reference to libz.so.1)
cmake -G Unix Makefiles ~/PropWare-release-2.0 -- The C compiler identification is unknown -- The CXX compiler identification is unknown -- The ASM compiler identification is GNU -- Found assembler: ~/propgcc/bin/propeller-elf-gcc -- The COGC compiler identification is unknown -- The COGCXX compiler identification is unknown -- The ECOGC compiler identification is unknown -- The ECOGCXX compiler identification is unknown -- LOADED: Generic-gcc-Propeller.cmake -- Check for working C compiler: ~/propgcc/bin/propeller-elf-gcc -- Check for working C compiler: ~/propgcc/bin/propeller-elf-gcc -- broken CMake Error at ~/cmake-3.0.2-Linux-i386/share/cmake-3.0/Modules/CMakeTestCCompiler.cmake:61 (message): The C compiler "~/propgcc/bin/propeller-elf-gcc" is not able to compile a simple test program. It fails with the following output: Change Dir: ~/PropWare-release-2.0/bin/CMakeFiles/CMakeTmp Run Build Command:"/usr/bin/make" "cmTryCompileExec1823009790/fast" /usr/bin/make -f CMakeFiles/cmTryCompileExec1823009790.dir/build.make CMakeFiles/cmTryCompileExec1823009790.dir/build make[1]: Entering directory `~/PropWare-release-2.0/bin/CMakeFiles/CMakeTmp' ~/cmake-3.0.2-Linux-i386/bin/cmake -E cmake_progress_report ~/PropWare-release-2.0/bin/CMakeFiles/CMakeTmp/CMakeFiles 1 Building C object CMakeFiles/cmTryCompileExec1823009790.dir/testCCompiler.c.obj ~/propgcc/bin/propeller-elf-gcc -o CMakeFiles/cmTryCompileExec1823009790.dir/testCCompiler.c.obj -c ~/PropWare-release-2.0/bin/CMakeFiles/CMakeTmp/testCCompiler.c ~/propgcc/bin/../lib/gcc/propeller-elf/4.6.1/../../../../propeller-elf/bin/as: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory make[1]: *** [CMakeFiles/cmTryCompileExec1823009790.dir/testCCompiler.c.obj] Error 1 make[1]: Leaving directory `~/PropWare-release-2.0/bin/CMakeFiles/CMakeTmp' make: *** [cmTryCompileExec1823009790/fast] Error 2 CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:8 (project) -- Configuring incomplete, errors occurred! See also "~/PropWare-release-2.0/bin/CMakeFiles/CMakeOutput.log". See also "~/PropWare-release-2.0/bin/CMakeFiles/CMakeError.log". Traceback (most recent call last): File "INSTALL.py", line 562, in <module> installer.install() File "INSTALL.py", line 109, in install self._build_binaries() File "INSTALL.py", line 167, in _build_binaries raise CMakeFailedException() __main__.CMakeFailedExceptionIn the meantime, I've found a GREAT benefit to PropWare! If you're using PropWare's classes for serial communication (such as `pwOut.printf("...")`) then you can increment the baud rate in your propeller-load configure script which will yield significantly faster transfer of your program as well as faster comms during runtime! The default configure script for the quickstart looks like this:
# quickstart.cfg clkfreq: 80000000 clkmode: XTAL1+PLL16X baudrate: 115200 rxpin: 31 txpin: 30 # cache geometry - 128 * 64 = 8192 byte cache index-width: 7 # 2^7 = 128 cache lines offset-width: 6 # 2^6 = 64 byte cache lines cache-geometry: ({index-width} << 8) | {offset-width} xmem-driver: eeprom_xmem.dat eeprom-first: TRUEand all you have to do is change it to read (notice line 5, "baudrate: 230400")
# quickstart.cfg clkfreq: 80000000 clkmode: XTAL1+PLL16X baudrate: 230400 rxpin: 31 txpin: 30 # cache geometry - 128 * 64 = 8192 byte cache index-width: 7 # 2^7 = 128 cache lines offset-width: 6 # 2^6 = 64 byte cache lines cache-geometry: ({index-width} << 8) | {offset-width} xmem-driver: eeprom_xmem.dat eeprom-first: TRUEAnd that's it! I'm thrilled with this, and rather surprised I didn't think to do it earlier. PropWare's serial classes already get their default baud rate from propeller-load, so any value you set in this script will be picked up during flashing - no need for any code changes!
NOTE: This will not work with most other serial implementations, including the standard Parallax utilities (printf, cout, print, printi, __simple_printf, etc).
Still.... I can deal with 460,800 baud!
Second: PropWare can finally read files from an SD card again! This was a huge effort to refactor my old SD class (which was 2,600 lines of code), but I'm nearly done! What used to be a single class - PropWare::SD - is now many classes. The basics looks like this:
I know - that's a lot more lines of code than the Parallax method - but this gets us a few things:
1) Object-oriented file handling
2) Each file can have its own buffer or share the common buffer for the filesystem (default). This is selectable on a per-file basis at runtime.
3) The class hierarchy was built with the goal of being extendable. Using PropWare as a base, the Propeller community could soon be reading from floppy disks. Or CDs. Or hard drives. Or a different file system (like ext4 or ntfs.... although I have no idea if we have RAM space for that).
PropWare's system seems to use about 1kB more space in LMM than Parallax's fopen and fgetc. Personally... I'm willing to live with this. I'll see if there are optimization that can be made, but this is a great starting point.
Next on my list: writing data back to the file!
Hopefully this makes moving to PropWare a bit less awkward for new users, and will encourage more folks to give PropWare's Printer class a try.
For reference though, the website (http://david.zemon.name/PropWare) is always pointing to the nightly branch, so there's a chance that it might look different from what you have locally.
I've also started using CMake's CPack for creating the zips instead of my own Python script. A minor implementation detail, but very nice for me none-the-less
This reorg should make getting started for new users much easier and more clear.
Let me know your thoughts!
I still run some older version, somewhere in Germany near the coast. Need to update it. Them code-duplicate runners are awfully painful. They stuck your nose right into it like lint and jslint do.
Enjoy!
Mike
....
...
PropWare works on a raspberry pi! I did have to compile CMake from source though. I have not uploaded the binary anywhere and don't have immediate plans to. Compiling is quite straight forward though:
the cmake command and make will both take a long time, but they worked first try for me. If you're running a pi 2, run "make -j3" instead of "make".
With that done, download PropGCC as linked by this thread or from the TeamCity user interface.
Once that is done, add cmake to the PATH in .bashrc.
Add PROPWARE_PATH and PROPGCC_PREFIX as environment variables
build PropWare
However, UART routines just sped up significantly. Max (transmit) speed is now 4.4 MBaud and an average rate of 2.7 Mbps can be held at that baud when invoked via the send_array or puts routines! With this, PropWare finally ranks right up there with other high-speed Propeller serial comms... and it's still just as configurable as before! And small! The most up-to-date specs for speed can always be found here.
That might provide a nice interim solution. I'm hoping to provide a solution that doesn't require use of a second cog though (now that I'm really getting the hang of inline assembly).
When I first picked it up I expected a simple serial routine using standard UART protocol or maybe I2C... but this thing is just too weird lol
You bring up a good point. Write-only devices are actually perfect examples of where a dedicated cog makes perfect sense - send the data to a buffer and then let it do the work on its own time. I think I'll do that. I'm used to things like ADCs and SD cards where you end up doing a blocking call anyway because you're waiting to read data back in. In those cases, dedicated cog is just a waste of hardware! Interesting that my ADC and SD routines both rely on SPI (dedicated cog) and my UART routines are inline assembly... I seem to have gotten things a tad backwards