I've taken a brief break from PWEdit and created a new peripheral for the MCP2515 CAN bus controller. Here's an example of using it in loopback mode to send three messages and filter such that only two of them are received:
As you can see, -Os is still hanging around. Changing the model worked, turning off 32 bit doubles worked in another test. I'm using CLion, if it makes any difference. This could very, very easily be user error on my part.
Thank you for reporting this! Turns out it's a typo on my end. There's a few ways to fix this:
1) Change your code to use the incorrectly spelled version: "AUTO_OTPIMIZATION"
2) Change the file "FindPropWare.cmake" in the PropWare installation directory and change "AUTO_OTPIMIZATION" to "AUTO_OPTIMIZATION"
3) Download either an updated 3.x pre-release or version 2.1.1, both of which I will release tomorrow evening after fixing the typo
Thrilled to see another CLion user! It is truly fantastic isn't it? I'm really looking forward to 2016.2 which they say might finally come with remote-debugging capability! That's one big step closer to working with more embedded systems!
Thrilled to see another CLion user! It is truly fantastic isn't it? I'm really looking forward to 2016.2 which they say might finally come with remote-debugging capability! That's one big step closer to working with more embedded systems!
Just curious, what OS are you running?
I've only had it for a day or so, but so far it's just as easy and intuitive as the other JetBrains stuff I've used. Sure beats trying to cargo-cult-cobble together a build system for (the also excellent) Sublime Text.
Ping_Demo.cpp doesn't work as posted. CLion says it "Cannot find ping.h" when I include <PropWare/Ping.h>, and that it "Can't resolve type 'Ping'" when I tried including "ping.h" instead.
Not worth noting: some errors rate "Cannot", while others get "Can't". Subtle artistry, IDE.
It's possible you have PropWare 3.x installed but are referencing 2.x documentation. If that's the case, refer to the documentation for the develop branch, which is here: http://david.zemon.name/PropWare-develop/ and specifically, Ping_Demo.cpp. You notice the include paths changed drastically between 2.x and 3.x. I do apologize for that, but it needed to happen.
Okay, looks like I had the documentation wrong in the "Detailed Description" of the Ping class in the develop branch. I've pushed out the fix and updated the documentation.
Apparently I never did anything with the 2.1.1 deb after downloading it, so I was running 2.0.1. I somehow managed to miss the fact that I even COULD run 3.x, and will start using it immediately.
Glad to hear it! Do be aware that 3.x is still in development (pre-release), so you might run into snags. Do please let me know if that happens and I'll get it fixed quick as I can. I'm also not 100% finalized on the folder structure... I think I like it... but I'm still open for suggestions and considering other options. See here for a list of what's been done so far: https://github.com/parallaxinc/PropWare/milestone/4
setting COMMON_FLAGS seems to have stopped working since the last time I tried it, nothing added to it shows up in the verbose cmake output, and setting 32_BIT_DOUBLE to OFF but adding -m32bit-doubles to COMMON_FLAGS doesn't appease the libraries that need it, and no optimizations are applied after disabling AUTO_OPTIMIZATION, etc.
I switched to 3.0.0.83 on Ubuntu 16.04 between now and when I was last aware of it working, so maybe botched some part of the reinstall.
Also, is Appendix A floating around anywhere? I'd like to read what it says about cmake for propware.
Okay, I've reproduced the issue with COMMON_FLAGS variable not doing anything in v3.x. I'll tackle this tonight, after work and let you know when its fixed.
setting COMMON_FLAGS seems to have stopped working since the last time I tried it, nothing added to it shows up in the verbose cmake output, and setting 32_BIT_DOUBLE to OFF but adding -m32bit-doubles to COMMON_FLAGS doesn't appease the libraries that need it, and no optimizations are applied after disabling AUTO_OPTIMIZATION, etc.
Thanks for the bug report. 3.0.0.84 fixes the issue. Download here.
Also, is Appendix A floating around anywhere? I'd like to read what it says about cmake for propware.
Oh, I hate to be the bearer of bad news. That reference to "Appendix A" must have been copied/pasted from another page. I looked through the git history and apparently that is what used to be "Appendix A." That's all the documentation there is on PropWare's build system.
However, if you're using 3.x, be sure to reference the 3.x PropWare documentation at http://david.zemon.name/PropWare-develop/ instead of the 2.x docs at http://david.zemon.name/PropWare/. I'll see about adding a banner to the top of the 2.x documentation to make it more obvious that there are two different places where documentation can be found.
Do please let me know (with posts here or feel free to submit issues to the issue tracker) if you find any other bugs or would like documentation updated. I'm going to take the rest of tonight at least to run through the docs and see what all I can add and update.
The latest development build of PropWare, 3.0.0.90, adds two buffered UART options.
1) An example shown in PropWare_BufferedUART. This uses PropWare's existing UARTTX and UARTRX classes in independent COG drivers to transmit and receive asynchronously.
2) A new class in the PropWare namespace, PropWare::FullDuplexSerial, which is a front-end to the tried-and-true FullDuplexSerial driver code. An example showing its usage can be found in PropWare_FullDuplexSerial.
The PropWare::FullDuplexSerial driver is quite efficient in terms of code size. It's been added to Hello_Demo so that one can easily compare it to the other drivers. Using the PropWare::Printer::printf method results in 5,680 bytes when backed by a PropWare::UARTTX object but only 5,076 bytes when backed by PropWare::FullDuplexSerial.
Comparing PropWare::UART and children with PropWare::FullDuplexSerial
You might ask yourself: "Why would I ever use the UARTTX and UARTRX classes when they're larger than FDS and they're not even buffered?"
The original objects have a few benefits:
1) UART children do not require a dedicated cog. They can be invoked from any cog at any time.
2) UART children support significantly higher baud rates (up to 4.4 MBaud transmit and 2.7 MBaud receive). Depending on your memory model and baud rate, they may require significantly more than one stop bit. However, FDS tops out at 1 Mbaud transmit and approximately 250 kbaud receive.
3) UART children support different configuration options, such as variable stop bits, parity, and up to 16 data bits per word.
But of course, FDS offers
1) Asynchronous execution
2) Smaller code
3) Different configuration options: invert tx, invert rx, and ignore TX/echo on RX (open-drain/source TX is available via SharedUARTTX)
Be aware of the requirements for your project and choose the UART implementation that best fits your needs. The important part is that both sets of classes implement the PropWare::PrintCapable and PropWare::ScanScapable interfaces, so you can effortlessly swap backends on a whim.
I've moved away from Doxygen as the soul web framework. Doxygen is now used only for the API docs and example projects. A simple AngularJS + Bootstrap framework is used to house the rest of the documentation, such as download and getting started instructions.
The files had to undergo significant changes (though the content should be the same still), so do please let me know if you see any issues and I'll get them fixed. I'm also interested in hearing anyone's opinion on the new site and how it could be improved. Now that it's built with Angular instead of Doxygen, I have a lot more freedom to do as I please with it.
This page hopefully takes care of the dire need for better documentation on PropWare's build system. Please take a look at it, and other pages; I'm interested to here any criticism you might have.
Bad news. It looks to me like PropWare is incompatible with PropGCC build 2408, which is what ships with SimpleIDE. I've also been unable to get anything in SimpleIDE working correctly under a new version of PropGCC (though that could very well be my own fault, not a bug in SimpleIDE/PropGCC/anything else).
I suspect it has something to do with one or more of the many bugs and features that have been tackled since build 2408.
Some parts of PropWare work. Others don't (it's not an all or nothing deal). Perhaps an older version of PropWare (the 2.x release?) would work... I don't know. I was able to confirm with certainty that the PropWare::SD class does not function correctly, though others such as PropWare::Pin and PropWare::SimplePort do. PropWare::Printer also works, but it seems the underlying implementation does not, because the pwOut instance doesn't work. I was able to confirm PropWare::Printer works by testing the SimplePrinter as shown in this example.
I'm pretty saddened and annoyed by this... I do hope Parallax is willing to work with the community to get SimpleIDE upgraded to a new version of PropGCC, and soon.
Not via the printer interface. You'll need to use the HD44780 object (if you're using a parallel port) or the UART object (if you're using something like parallax's serial lcd) to do that.
If you're using the parallel interface (and therefore the HD44780 class), you can use the move() method to place the cursor where you like. However, the HD44780 class does support newline (\n), carriage return (\r), and tab characters (\t) which may negate the need for manual cursor movement. Tabs are hardcoded for 4-character widths via a constant at the top of the HD44780 class.
If you're using a serial interface, then you'd have to read the documentation for the specific serial driver and then send the appropriate commands via the raw serial driver (such as UARTTX::send_array).
Hey folks. Just thought I'd warn any PropWare users that the v3.0 branch (develop) just saw a breaking change to the unit test framework (PropWareTests.h). I've introduced the ability to use "test fixtures" to ease setup/teardown methods. The following simple sample must now be converted to the new "procedural" version or new "test fixture" version.
#include "PropWareTests.h"
class MyClass {
public:
int getTheAnswer() {
return 42;
}
};
MyClass *testable;
void setUp() {
testable = new MyClass();
}
TEARDOWN {
delete testable;
}
TEST(ShouldDoStuff) {
setUp();
ASSERT_EQ_MSG(42, testable->getTheAnswer());
tearDown();
}
int main () {
START(MyClassTest);
RUN_TEST(ShouldDoStuff);
COMPLETE();
}
Procedural Version
Note that the only difference is the "TEARDOWN" macro has disappeared because you should be using test fixtures if you have a common teardown routine.
#include "PropWareTests.h"
class MyClass {
public:
int getTheAnswer () {
return 42;
}
};
MyClass *testable;
void setUp () {
testable = new MyClass();
}
void tearDown () {
delete testable;
}
TEST(ShouldDoStuff) {
setUp();
ASSERT_EQ_MSG(42, testable->getTheAnswer());
tearDown();
}
int main () {
START(MyClassTest);
RUN_TEST(ShouldDoStuff);
COMPLETE();
}
Test Fixture
Woo hoo! Take advantage of constructors and destructors to do any setup or teardown. This allows for far less dynamic allocation: notice that "testable" is no longer a pointer! An instance of "MyClassTest" will be created and destroyed for every individual test.
#include "PropWareTests.h"
class MyClass {
public:
int getTheAnswer () {
return 42;
}
};
class MyClassTest {
public:
MyClass testable;
};
TEST_F(MyClassTest, ShouldDoStuff) {
ASSERT_EQ_MSG(42, testable.getTheAnswer());
}
int main () {
START(MyClassTest);
RUN_TEST_F(MyClassTest, ShouldDoStuff);
COMPLETE();
}
@"Clock Loop"... it just occurred to me... you're creating nix packages for everything under the sun... is PropWare one of them? I already ship deb and rpm packages built by CMake, but I wonder how hard it would be to add a PropWare package to nix?
you're creating nix packages for everything under the sun... is PropWare one of them? I already ship deb and rpm packages built by CMake, but I wonder how hard it would be to add a PropWare package to nix?
I am just starting to get back into coding, and c ... its been a while...
I have no idea what I am doing with all this.. just learning and documenting about it as I do.
I can throw it on! I ran into a dead end when I used QT5.11 to make simpleIDE.
It broke it, I will not move to QT5.4 so that will sit until I or someone else fixes it.
It works mostly, just some features are broken, and even QT5.11 creator lets you see the bugs, it points them out, I just don't know what to do, or how involved it is.
I need a dev tool that can make cross platform programs for interfacing programs to the propeller via wifi or usb on the users pc.
And qt , even in its mess, has come back to my plate MULTIPLE times over the past 3 years...
I haven't even looked at propware at all.
(reading about it now)
Ahh, I code the prop in spin, thus why I am new to all this. The OBEX has been my "propware"
Whoops! I tagged the wrong person. I was thinking it was you that started the Nix stuff on these forums, but it was @__red__ wasn't it? Sorry about that!
Whoops! I tagged the wrong person. I was thinking it was you that started the Nix stuff on these forums, but it was @__red__ wasn't it? Sorry about that!
is PropWare one of them? I already ship deb and rpm packages built by CMake, but I wonder how hard it would be to add a PropWare package to nix?
You can get nix to compile pretty much anything, the difficulty is getting upstream to support it. They are all a bunch of FP purists so getting packages into the global network can be 'challenging'. They'll frequently insist that you try and fix upstream package buildsystems instead of having Nix do the packaging instead.
That was what caused the latency in getting the packages added globally and why I ended up going for a 'private repo' type setup.
To be clear, I'm not adverse in the slightest to pushing 'fixes' (which they would define as being a more standard use of GNU buildtools, removal f hard-coded values etc...) upstream - it just always felt to me that asking our fine developers to change the way they build their code was like teaching Granny how to suck eggs.
PropWare isn't in there yet - I can almost certainly add it.
One Win/Win solution for integrating PropWare is that as I understand it it's an integration of a whole bunch of stuff and you're the developer.
This means if your build-system for PropWare is more 'standard' in that respect we can get the whole kit/kaboodle in the global Nix cache in one package cross-platform and easily without having to disturb others.
Lemme take a look at your build-system and we'll talk.
Also - related...
I went looking for an existing IRC channel for propeller stuff and couldn't find one.
I'm going to hang-out on freenode, #propellerII for a while and see if anyone joins me. I'll also be joining the wikibot to that channel so when people add/modify content it will notify people in the channel.
I made some long-overdue changes to the build system and installers this weekend. Specifically, issues 150, 151, and 152.
With the exception of the Windows exe installer, there are NO MORE system binaries in the PropWare package. No longer does PropWare ship with Spin2Cpp or CMake binaries in Linux and no longer am I providing a Mac OSX CMake package with the PropWare build system pre-installed inside it. There were numerous reasons for making this change, some include:
- Much smaller installer size
- Allow the user to select their own CMake version
- No more updates to PropWare just because a newer version of CMake was release
- ARCHITECTURE INDEPENDENCE! I'm very excited about this because PropWare's .deb and .rpm packages as created by my CI server can now be installed directly onto Raspberry Pis or any other non-x86 hardware.
What made this possible?
The biggest thing that has changed since I started packaging CMake with PropWare is time. I started using a feature from CMake version 3.3 very soon after its release and it was not commonly available on any Linux distribution at the time. Since then, CMake v3.3+ is available on a plethora of Linux distributions from their upstream package maintainers.
I've also updated the FindPropWare.cmake script to be much smarter. I've learned a lot about CMake since the last time I made any significant changes, and it was time for an overhaul. Post-install and pre-removal scripts have been added to the deb and rpm packages which will create symlinks in your system's CMake installation directory that point back to FindPropWare.cmake - this allows you to use the line "find_package(PropWare REQUIRED)" without configuring "CMAKE_MODULE_PATH" first. Once inside FindPropWare.cmake, the script will resolve the symlink to determine the real directory of the PropWare build system and set "CMAKE_MODULE_PATH" for you.
The pre/post install scripts have been tested to work on both Ubuntu and Fedora with both the system-installed CMake package as well as a custom installation from CMake.org which is extracted into /usr/local.
Another roadblock to making this happen was my usage of Spin2Cpp. PropWare's build system was not written correctly to handle a system where Spin2Cpp was not installed, despite the fact that 90% of its functionality did not depend on Spin2Cpp. I've fixed that and PropWare now functions perfectly fine without Spin2Cpp.
PropWare-build is now usable without PropWare-built libraries
It was always my intention that you could be able to use PropWare's build system without any of the libraries that I build with PropWare. You could be able to use PropWare-build directly in your project without anything else from me. Unfortunately, some poor coding decisions on my part prevented that from being true. You, in fact, needed the entire suite of PropWare-built libraries to use any part of PropWare's build system. That has now been fixed.
No warnings for Simple headers
Headers are now installed into two different folders "include" and "include/c++". This allowed me to add "-isystem <root>/include" instead of "-I <root>/include" for the Simple library headers. For those that don't know: "-isystem" informs the compiler that any headers in that directory are "system" headers that the user does not want to be warned about. This allows you to compile with very strict warnings on your application code without getting warned about poor choices made by library authors. Unfortunately... "-isystem" forces the header to be interpreted as C and therefore can not be used to include C++ headers. I do not know if this is considered a bug and is fixed in later versions of GCC, but it is a thing in GCC 4.6 so we're stuck with it for the time being.
Transitive Dependencies
I don't think many users will notice the effects of this, but I have started taking advantage of CMake's transitive dependency features. If you want to do something really custom and not use create_simple_executable() or create_executable(), your life should be a bit easier now.
CMake Namespace
Another change that you'll only notice if you're not using create_simple_executable() or create_executable(): I've added a CMake namespace to all of the libraries exported by PropWare. Instead of referencing "PropWare_cmm" or "Simple_lmm" you would now reference "PropWare::PropWare_cmm" or "PropWare::Simple_lmm". Namespaces are feature that help the "fail fast" philosophy. If "PropWare_cmm" can't be found, you will not aware until the linker fails to find undefined symbols. If "PropWare::PropWare_cmm" can not be found, CMake will throw an error during the configuration phase, even before the compilation phase, and give you (somewhat) helpful error message telling you how you might fix it.
And, in other news, I used PropWare to interface with Microchip's CryptoAuth chips (ATSHA204A, ATECC608A) last week and this weekend. The following repository is NOT meant to be a tutorial on how to use the chip (I'm still looking for one myself, actually) but it does contain the necessary HAL code so that the CryptoAuthLib can use PropWare as its underlying communications layer. At the moment, I've verified that I can get the device revision information and its serial number, which is enough to confirm that the HAL layer is working correctly.
Comments
Verbose/commented version on GitHub here.
#include <PropWare/PropWare.h> #include <PropWare/hmi/output/printer.h> #include <PropWare/serial/can/mcp2515.h> using namespace PropWare; const Port::Mask MOSI = Port::P0; const Port::Mask MISO = Port::P1; const Port::Mask SCLK = Port::P2; const Port::Mask CS = Port::P7; const Port::Mask CLOCK_MASK = Port::P8; const uint8_t messages[][6] = { "Hello", "David", "Katie" }; void read (MCP2515 &can, const MCP2515::BufferNumber bufferNumber) { if (can.check_receive_buffer(bufferNumber)) { uint8_t buffer[MCP2515::MAX_DATA_BYTES]; uint8_t bytesRead; can.read_message(bufferNumber, &bytesRead, buffer); pwOut << "Message: `" << (const char *) buffer << "`\n"; } else { pwOut << "No message\n"; } } int main () { const SPI spi(MOSI, MISO, SCLK); MCP2515 can(spi, CS); const Pin clock(CLOCK_MASK, Pin::OUT); clock.start_hardware_pwm(8000000); can.start(MCP2515::BAUD_1000KBPS, MCP2515::LOOPBACK); can.set_mask(MCP2515::BUFFER_0, WORD_0); can.set_filter(MCP2515::FILTER_0, 2); pwOut << "Expected message received:\n"; can.send_message(2, 6, messages[0]); read(can, MCP2515::BUFFER_0); pwOut << "Message should _not_ be received!\n"; can.send_message(3, 6, messages[1]); read(can, MCP2515::BUFFER_0); pwOut << "Expected message received:\n"; can.send_message(2, 6, messages[2]); read(can, MCP2515::BUFFER_0); }My CMakeLists.txt:
cmake_minimum_required(VERSION 3.3) find_package(PropWare REQUIRED) set(BOARD ROBOPI) project(roombaPropNew CXX) set(MODEL cmm) set(AUTO_OPTIMIZATION OFF) set(COMMON_FLAGS -O1) create_simple_executable(${PROJECT_NAME} NeuralNet.cpp NeuralNet.h roomba_network.cpp) set(CMAKE_VERBOSE_MAKEFILE ON)The relevant parts of the verbose make output (-O1 chosen at random for purposes of this test);
As you can see, -Os is still hanging around. Changing the model worked, turning off 32 bit doubles worked in another test. I'm using CLion, if it makes any difference. This could very, very easily be user error on my part.
1) Change your code to use the incorrectly spelled version: "AUTO_OTPIMIZATION"
2) Change the file "FindPropWare.cmake" in the PropWare installation directory and change "AUTO_OTPIMIZATION" to "AUTO_OPTIMIZATION"
3) Download either an updated 3.x pre-release or version 2.1.1, both of which I will release tomorrow evening after fixing the typo
Thrilled to see another CLion user! It is truly fantastic isn't it? I'm really looking forward to 2016.2 which they say might finally come with remote-debugging capability! That's one big step closer to working with more embedded systems!
Just curious, what OS are you running?
I've only had it for a day or so, but so far it's just as easy and intuitive as the other JetBrains stuff I've used. Sure beats trying to cargo-cult-cobble together a build system for (the also excellent) Sublime Text.
I'm running Ubuntu 14.04.
Not worth noting: some errors rate "Cannot", while others get "Can't". Subtle artistry, IDE.
What version of PropWare are you running? The version is specified in <PropWare installation>/version.txt
It's possible you have PropWare 3.x installed but are referencing 2.x documentation. If that's the case, refer to the documentation for the develop branch, which is here: http://david.zemon.name/PropWare-develop/ and specifically, Ping_Demo.cpp. You notice the include paths changed drastically between 2.x and 3.x. I do apologize for that, but it needed to happen.
update: everything is beautiful and nothing hurts
https://github.com/parallaxinc/PropWare/milestone/4
I switched to 3.0.0.83 on Ubuntu 16.04 between now and when I was last aware of it working, so maybe botched some part of the reinstall.
Also, is Appendix A floating around anywhere? I'd like to read what it says about cmake for propware.
Thanks for the bug report. 3.0.0.84 fixes the issue. Download here.
Oh, I hate to be the bearer of bad news. That reference to "Appendix A" must have been copied/pasted from another page. I looked through the git history and apparently that is what used to be "Appendix A." That's all the documentation there is on PropWare's build system.
However, if you're using 3.x, be sure to reference the 3.x PropWare documentation at http://david.zemon.name/PropWare-develop/ instead of the 2.x docs at http://david.zemon.name/PropWare/. I'll see about adding a banner to the top of the 2.x documentation to make it more obvious that there are two different places where documentation can be found.
Do please let me know (with posts here or feel free to submit issues to the issue tracker) if you find any other bugs or would like documentation updated. I'm going to take the rest of tonight at least to run through the docs and see what all I can add and update.
1) An example shown in PropWare_BufferedUART. This uses PropWare's existing UARTTX and UARTRX classes in independent COG drivers to transmit and receive asynchronously.
2) A new class in the PropWare namespace, PropWare::FullDuplexSerial, which is a front-end to the tried-and-true FullDuplexSerial driver code. An example showing its usage can be found in PropWare_FullDuplexSerial.
The PropWare::FullDuplexSerial driver is quite efficient in terms of code size. It's been added to Hello_Demo so that one can easily compare it to the other drivers. Using the PropWare::Printer::printf method results in 5,680 bytes when backed by a PropWare::UARTTX object but only 5,076 bytes when backed by PropWare::FullDuplexSerial.
Comparing PropWare::UART and children with PropWare::FullDuplexSerial
You might ask yourself: "Why would I ever use the UARTTX and UARTRX classes when they're larger than FDS and they're not even buffered?"
The original objects have a few benefits:
1) UART children do not require a dedicated cog. They can be invoked from any cog at any time.
2) UART children support significantly higher baud rates (up to 4.4 MBaud transmit and 2.7 MBaud receive). Depending on your memory model and baud rate, they may require significantly more than one stop bit. However, FDS tops out at 1 Mbaud transmit and approximately 250 kbaud receive.
3) UART children support different configuration options, such as variable stop bits, parity, and up to 16 data bits per word.
But of course, FDS offers
1) Asynchronous execution
2) Smaller code
3) Different configuration options: invert tx, invert rx, and ignore TX/echo on RX (open-drain/source TX is available via SharedUARTTX)
Be aware of the requirements for your project and choose the UART implementation that best fits your needs. The important part is that both sets of classes implement the PropWare::PrintCapable and PropWare::ScanScapable interfaces, so you can effortlessly swap backends on a whim.
http://david.zemon.name/PropWare/
I've moved away from Doxygen as the soul web framework. Doxygen is now used only for the API docs and example projects. A simple AngularJS + Bootstrap framework is used to house the rest of the documentation, such as download and getting started instructions.
The files had to undergo significant changes (though the content should be the same still), so do please let me know if you see any issues and I'll get them fixed. I'm also interested in hearing anyone's opinion on the new site and how it could be improved. Now that it's built with Angular instead of Doxygen, I have a lot more freedom to do as I please with it.
I have a simple CMakeLists.txt file:
And if I add the line "set(CMAKE_EXPORT_COMPILE_COMMANDS ON)"
Then it also generates a json file with the following content:
[ { "directory": "/home/david/reusable/Documents/Programming/PropellerProjects/Scratch/bin", "command": "/opt/parallax/bin/propeller-elf-gcc -Os -m32bit-doubles -Wall -ffunction-sections -fdata-sections -save-temps --std=gnu++0x -fno-exceptions -fno-rtti -fno-threadsafe-statics -mcmm -I/usr/PropWare/include -o CMakeFiles/Scratch.dir/main.cpp.obj -c /home/david/reusable/Documents/Programming/PropellerProjects/Scratch/main.cpp", "file": "/home/david/reusable/Documents/Programming/PropellerProjects/Scratch/main.cpp" } ]Official CMake documentation for the feature can be found here: https://cmake.org/cmake/help/v3.5/variable/CMAKE_EXPORT_COMPILE_COMMANDS.html
This page hopefully takes care of the dire need for better documentation on PropWare's build system. Please take a look at it, and other pages; I'm interested to here any criticism you might have.
I've also added a page that describes how to build PropWare from source: http://david.zemon.name/PropWare/#/reference/build-from-source
Next up: more and better CMake examples on this page: http://david.zemon.name/PropWare/#/reference/cmake-by-example
Discovery
I suspect it has something to do with one or more of the many bugs and features that have been tackled since build 2408.
Some parts of PropWare work. Others don't (it's not an all or nothing deal). Perhaps an older version of PropWare (the 2.x release?) would work... I don't know. I was able to confirm with certainty that the PropWare::SD class does not function correctly, though others such as PropWare::Pin and PropWare::SimplePort do. PropWare::Printer also works, but it seems the underlying implementation does not, because the pwOut instance doesn't work. I was able to confirm PropWare::Printer works by testing the SimplePrinter as shown in this example.
I'm pretty saddened and annoyed by this... I do hope Parallax is willing to work with the community to get SimpleIDE upgraded to a new version of PropGCC, and soon.
I'm trying to use the printer class to have my Propeller Activity Board display stuff to a 16x2 character LCD. Is there a way to set the position of the cursor? I couldn't find anything that would let me do so on https://david.zemon.name/PropWare/api-develop/classPropWare_1_1Printer.xhtml .
If you're using the parallel interface (and therefore the HD44780 class), you can use the move() method to place the cursor where you like. However, the HD44780 class does support newline (\n), carriage return (\r), and tab characters (\t) which may negate the need for manual cursor movement. Tabs are hardcoded for 4-character widths via a constant at the top of the HD44780 class.
If you're using a serial interface, then you'd have to read the documentation for the specific serial driver and then send the appropriate commands via the raw serial driver (such as UARTTX::send_array).
#include "PropWareTests.h" class MyClass { public: int getTheAnswer() { return 42; } }; MyClass *testable; void setUp() { testable = new MyClass(); } TEARDOWN { delete testable; } TEST(ShouldDoStuff) { setUp(); ASSERT_EQ_MSG(42, testable->getTheAnswer()); tearDown(); } int main () { START(MyClassTest); RUN_TEST(ShouldDoStuff); COMPLETE(); }Procedural Version
Note that the only difference is the "TEARDOWN" macro has disappeared because you should be using test fixtures if you have a common teardown routine.
#include "PropWareTests.h" class MyClass { public: int getTheAnswer () { return 42; } }; MyClass *testable; void setUp () { testable = new MyClass(); } void tearDown () { delete testable; } TEST(ShouldDoStuff) { setUp(); ASSERT_EQ_MSG(42, testable->getTheAnswer()); tearDown(); } int main () { START(MyClassTest); RUN_TEST(ShouldDoStuff); COMPLETE(); }Test Fixture
Woo hoo! Take advantage of constructors and destructors to do any setup or teardown. This allows for far less dynamic allocation: notice that "testable" is no longer a pointer! An instance of "MyClassTest" will be created and destroyed for every individual test.
#include "PropWareTests.h" class MyClass { public: int getTheAnswer () { return 42; } }; class MyClassTest { public: MyClass testable; }; TEST_F(MyClassTest, ShouldDoStuff) { ASSERT_EQ_MSG(42, testable.getTheAnswer()); } int main () { START(MyClassTest); RUN_TEST_F(MyClassTest, ShouldDoStuff); COMPLETE(); }If you need more examples, see this commit.
I am just starting to get back into coding, and c ... its been a while...
I have no idea what I am doing with all this.. just learning and documenting about it as I do.
I can throw it on! I ran into a dead end when I used QT5.11 to make simpleIDE.
It broke it, I will not move to QT5.4 so that will sit until I or someone else fixes it.
It works mostly, just some features are broken, and even QT5.11 creator lets you see the bugs, it points them out, I just don't know what to do, or how involved it is.
I need a dev tool that can make cross platform programs for interfacing programs to the propeller via wifi or usb on the users pc.
And qt , even in its mess, has come back to my plate MULTIPLE times over the past 3 years...
I haven't even looked at propware at all.
(reading about it now)
Ahh, I code the prop in spin, thus why I am new to all this. The OBEX has been my "propware"
You called?
You can get nix to compile pretty much anything, the difficulty is getting upstream to support it. They are all a bunch of FP purists so getting packages into the global network can be 'challenging'. They'll frequently insist that you try and fix upstream package buildsystems instead of having Nix do the packaging instead.
That was what caused the latency in getting the packages added globally and why I ended up going for a 'private repo' type setup.
To be clear, I'm not adverse in the slightest to pushing 'fixes' (which they would define as being a more standard use of GNU buildtools, removal f hard-coded values etc...) upstream - it just always felt to me that asking our fine developers to change the way they build their code was like teaching Granny how to suck eggs.
PropWare isn't in there yet - I can almost certainly add it.
One Win/Win solution for integrating PropWare is that as I understand it it's an integration of a whole bunch of stuff and you're the developer.
This means if your build-system for PropWare is more 'standard' in that respect we can get the whole kit/kaboodle in the global Nix cache in one package cross-platform and easily without having to disturb others.
Lemme take a look at your build-system and we'll talk.
Also - related...
I went looking for an existing IRC channel for propeller stuff and couldn't find one.
I'm going to hang-out on freenode, #propellerII for a while and see if anyone joins me. I'll also be joining the wikibot to that channel so when people add/modify content it will notify people in the channel.
With the exception of the Windows exe installer, there are NO MORE system binaries in the PropWare package. No longer does PropWare ship with Spin2Cpp or CMake binaries in Linux and no longer am I providing a Mac OSX CMake package with the PropWare build system pre-installed inside it. There were numerous reasons for making this change, some include:
- Much smaller installer size
- Allow the user to select their own CMake version
- No more updates to PropWare just because a newer version of CMake was release
- ARCHITECTURE INDEPENDENCE! I'm very excited about this because PropWare's .deb and .rpm packages as created by my CI server can now be installed directly onto Raspberry Pis or any other non-x86 hardware.
What made this possible?
The biggest thing that has changed since I started packaging CMake with PropWare is time. I started using a feature from CMake version 3.3 very soon after its release and it was not commonly available on any Linux distribution at the time. Since then, CMake v3.3+ is available on a plethora of Linux distributions from their upstream package maintainers.
I've also updated the FindPropWare.cmake script to be much smarter. I've learned a lot about CMake since the last time I made any significant changes, and it was time for an overhaul. Post-install and pre-removal scripts have been added to the deb and rpm packages which will create symlinks in your system's CMake installation directory that point back to FindPropWare.cmake - this allows you to use the line "find_package(PropWare REQUIRED)" without configuring "CMAKE_MODULE_PATH" first. Once inside FindPropWare.cmake, the script will resolve the symlink to determine the real directory of the PropWare build system and set "CMAKE_MODULE_PATH" for you.
The pre/post install scripts have been tested to work on both Ubuntu and Fedora with both the system-installed CMake package as well as a custom installation from CMake.org which is extracted into /usr/local.
Another roadblock to making this happen was my usage of Spin2Cpp. PropWare's build system was not written correctly to handle a system where Spin2Cpp was not installed, despite the fact that 90% of its functionality did not depend on Spin2Cpp. I've fixed that and PropWare now functions perfectly fine without Spin2Cpp.
PropWare-build is now usable without PropWare-built libraries
It was always my intention that you could be able to use PropWare's build system without any of the libraries that I build with PropWare. You could be able to use PropWare-build directly in your project without anything else from me. Unfortunately, some poor coding decisions on my part prevented that from being true. You, in fact, needed the entire suite of PropWare-built libraries to use any part of PropWare's build system. That has now been fixed.
No warnings for Simple headers
Headers are now installed into two different folders "include" and "include/c++". This allowed me to add "-isystem <root>/include" instead of "-I <root>/include" for the Simple library headers. For those that don't know: "-isystem" informs the compiler that any headers in that directory are "system" headers that the user does not want to be warned about. This allows you to compile with very strict warnings on your application code without getting warned about poor choices made by library authors. Unfortunately... "-isystem" forces the header to be interpreted as C and therefore can not be used to include C++ headers. I do not know if this is considered a bug and is fixed in later versions of GCC, but it is a thing in GCC 4.6 so we're stuck with it for the time being.
Transitive Dependencies
I don't think many users will notice the effects of this, but I have started taking advantage of CMake's transitive dependency features. If you want to do something really custom and not use create_simple_executable() or create_executable(), your life should be a bit easier now.
CMake Namespace
Another change that you'll only notice if you're not using create_simple_executable() or create_executable(): I've added a CMake namespace to all of the libraries exported by PropWare. Instead of referencing "PropWare_cmm" or "Simple_lmm" you would now reference "PropWare::PropWare_cmm" or "PropWare::Simple_lmm". Namespaces are feature that help the "fail fast" philosophy. If "PropWare_cmm" can't be found, you will not aware until the linker fails to find undefined symbols. If "PropWare::PropWare_cmm" can not be found, CMake will throw an error during the configuration phase, even before the compilation phase, and give you (somewhat) helpful error message telling you how you might fix it.
https://github.com/DavidZemon/PropCryptoAuth