David, the version I'm using identifies itself as propellergcc_v1_0_0_2408 - is this from the default branch?
No, that's probably the version that comes with SimpleIDE which is the release_1_0 branch. Here is what I get from a default branch build:
david-betzs-macbook-pro:ornament_2014 dbetz$ propeller-elf-gcc --version
propeller-elf-gcc (propellergcc-alpha_v1_9_0_2403) 4.6.1
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
@MJB - You'll a need a command line program to load the modules into the Tachyon Kernel. I suppose the easiest thing you can do is write a python script. The python script then can be invoked by cmake. That said, tell me what exactly you'd like to get working first and we can walk through those details. I'm almost done with a spin library which I suppose the kernel can leverage.
@DavidBetz - I don't have the ability to build propeller-gcc. I depend on precompiled binaries. So, I don't have the default branch to test with.
@PhiPi - Almost done with a spin version of the interface library for the propeller. I just need to switch out the serial driver for my own custom driver with larger fifo buffers and add flow control code as required by my protocol. That said, I have a demo ready right now which works more or less. However, since flow control is not operational I've slowed down the update loop in the demo as to not overload the IDE. Additionally, without flow control bytes may randomly get dropped if they are coming in to fast or the computer is not servicing them. If you see an error about a corrupted packet just reset the board which will also reset the IDE's serial parser.
@David, that would be very nice if you could do that.
@Kye, your advice and provided files work fine at first look, understanding how OC parses and runs things like the board files, etc., helps a lot.
Sorry to be a pest but I cannot see a simple way to make OC fully detach from the USB serial port to the Prop without doing Board->Serial Port->(any other port or None). The reason I would like this functionality is that I use a PC based program to interact with the Prop as part of the entire project and the port isn't released from OC unless it's deselected. Changing the port in OC triggers a remake, as it should, but this causes quite a delay that wouldn't exist if the port could optionally just be released by OC after the code load and reopened by OC at the next load in the case of a user, like me, who doesn't need the serial terminal widget access.
I can add this feature. But, its not so simple to do. I'd have to add extra state to the GUI to track if it should reopen a port after loading and new buttons to reconnect.
I can also just make the cmake script faster. Manually determining dependencies via cmake for .spin and .cogc files is what takes so long. I read up on a way to make this faster which I think would help. I can post a new version of the build system tonight for this.
Understood. Perhaps an option to only open the selected port when loading then close it after the load might be easier? That would be ideal . For now, I have enough pins open to where I'm going to connect to the PC app through a secondary USB/serial adapter as a workaround. I appreciate your consideration, the editing environment is very nice and I'm sure I'll segue into the graphing and logging options as my curiosity grows...
Understood. Perhaps an option to only open the selected port when loading then close it after the load might be easier? That would be ideal . For now, I have enough pins open to where I'm going to connect to the PC app through a secondary USB/serial adapter as a workaround. I appreciate your consideration, the editing environment is very nice and I'm sure I'll segue into the graphing and logging options as my curiosity grows...
Thanks!
I'll mark this feature for the v0.3 release. I'll have that out by January. Until then, I'm going have a patch release out by Friday with all the bugs fixed that you've discovered along with a spin interface library.
Superb! Another thought - could the total memory consumed/in-hub image size/I'm reaching for the right words/ be reported along with code space and data space? I see code % is code size/32768 and data % is data size/(32768-codesize) - it would be great to have the total consumed space reported as well so you know the immediate impact of any changes made in code and compiler switch changes.
Edit: Also, is there a way to enable line numbers to print along with the code? Perhaps Print Preview could be looked at as well? Please understand I'm NOT complaining or demanding in any way, just dropping train-of-thought ideas for potential improvement. As we all know all too well, the written word can very easily convey the wrong impression...
I don't know how the QtCreator back-end prints code. I'll look into trying to get that to work. However, it might be impossible without a large amount of work. If its easy I'll do it. If not, then you can try yourself. If you add that feature to my github repo as an enhancement request and I don't do it right now it might get done later. (There be more pressing issues to address than this)...
The code size mechanism kinda needs to support AVRs/PICs/etc. as well as the propeller. It makes more sense on the AVR because of that chip's Harvard architecture. Adding some more text to the compile output is an easy fix. However, for the GUI display I'll need a unified scheme. Right now since I'm using the third party Arduino-cmake build system I can't change it just yet. However, the Arduino-cmake build system is kinda abandoned so I'm going to have to roll my own. When that happens I can look at changing this up. What I have now is the best mechanism I could think of. The propeller really doesn't have data space per say... maybe I should just output code size and nothing else?
I appreciate the insight into your goals and constraints. Both of the issues I mentioned are extremely minor, especially the code size reporting. I'll be experimenting with QT Creator soon and will let you know if I find an easy way to add the line numbers to the print output but at a preliminary search it looks scary, as you've noted!
Feel free to change the CMake Build System to meet you needs. That's why I used CMake instead of putting the logic into the GUI. This frees you to do whatever you'd like.
However, printing is basically accomplished by the code manually drawing text on a page sized image and then sending that to the printer. I could probably get the feature working after a lot of trial and error but it is not easy. If you take a look at the code you'll see what I am talking about.
As for the image size stuff I made the data percentage now computed the same way as the code percentage. So, you can just add the two percentages to get the total space use now.
Additionally, I've also improved the build system to make it faster and more complete. You can now open .binary, .eeprom, and .elf files and load them along with improving spin and cogc file support.
Just unzip the attached files in the /ide/qtcreator/share/qtcreator/cmake-board-modules/propeller-cmake directory to update the build system for now.
I see what you mean there's a LOT going on under the hood for sure. I have my line number printing need taken care of by using an external command and an autoexec macro in another editor - kludgy but works. The updated build files seem to work just fine, good stuff!
Omnia Creator v0.3 for windows is now available. Version v0.3 features a new SPIN Interface Library and Examples too! Please visit www.omniacreator.com to download it now.
Version 0.3 includes a lot of fixes for propeller support. Compiling C/C++ code for the propeller has no problems now and similarly compiling spin code works perfectly too. The CMake build system now does dependency checking for both cogc and spin source files (in addition to normal c/cpp files). This allows Omnia Creator to determine what spin files are part of your project and if things need to be rebuilt after changes to source files. Also, the CMake build system automatically supplies include directories to cogc and spin files now making it easy to pull in the Omnia Creator Interface Library into your spin code. Omnia Creator can also now open .binary, .eeporm, and .elf files and load them for you. A new SPIN error parser highlights the error line when a compile fails. A new propeller-load error parser will display a message box if loading fails too. Previously you had to look in the compile output to see what was wrong.
Here are some screen shots of what you can do with Omnia Creator in SPIN:
The Interface Library allows you to easily create numerous XY plot widgets and send data to them from your microcontroller. Widgets can be arranged around the main code window to create whatever debug interface you desire.
Though the graph interface you can easily display information about signals in your system. Additionally, taking the FFT of a graph has never been easier. Just execute one line of code to turn FFT's on. Feel free to edit this demo to change the data sources too! The built-in source is just a bunch of boring generated sinusoidals.
The bar chart feature allows you to create bar charts easily in Omnia Creator. This demo just shows off displaying sin waves using bar charts. There are much better uses for this feature... but, not many easily demo-able ones.
If you want to make statistical boxes that is easy too. But... it's not easy to make cool looking pictures out of them.
***
Omnia Creator v0.3 also includes two more spin demos showing off how to create multiple serial terminals and send text to them along with another demo showing how to use the built-in serial port the interface library supplies to receive regular text data from serial terminals while plotting to widgets at the same time. The interface library runs at 115200 baud when connected to Omnia Creator and has a 256 byte receiver fifo buffer.
Other things... if the interface library cannot connect to Omnia Creator or spends more than 5 seconds waiting for a command response from Omnia Creator it will automatically disable itself causing all function calls to immediately return. This means you can just leave the interface library calls in your code and after you disconnect your project from Omnia Creator you only have to pay a 5 second startup time penalty before everything works fine.
***
Caveats - CMake is not able to read UTF-16 files. This prevents the build system from being able to parse spin files and determine their dependencies and what files are in the project. Also long as your top object is not UTF-16 Omnia Creator will still work but will complain about sub objects that are UTF-16 not being part of the project if you try to edit them (Omnia Creator's editor can edit UTF-16 files). Also, the C/C++ build system will not compile the dat sections from spin files into your project if the spin file is UTF-16 because it can't read the file to determine if a dat section is present.
This issue will get fixed whenever CMake supports UTF-16 files. I opened a bug tracker with CMake about this. Hopefully they apply this fix for the next CMake release.
If you want to see the propeller font in your code go to the tools->options and change the editor font to the parallax font and the utf-16 symbols in your code will display correctly. The default font is courier which does not have the propeller font symbols.
Thank you for adding Spin support to Omnia Creator. I look forward to trying it out.
This last Black Friday, I ordered a couple of these Pololu Jrk 21v3 motor controllers. One of the selling points Pololu lists for these controllers is their configuration utility.
As you can see from the above picture, the utility graphs a bunch of the feedback from the controller. I'm hoping Omnia Creator can be used to create something similar with the Propeller when used with a h-bridge and encoders.
I'm hoping this sort of feedback will make tuning motor control algorithms a bit easier.
Based on what you've posted, it looks like Omnia Creator should make displaying this sort of information relatively easy.
A long time back I git hold of a 8051 board and was instantly disillusioned that a printf was too much for the free edition of Kiel. I see from those screen grabs that it takes 13K (opt 8K) on a Prop. What would the minimum, and type of, memory that would make this practicable (as in the sort of stuff that you guys managed to stuff into 32K before?
Personally I would forget printf. if you just want the functionality that is available in Spin with FullDuplexSerial and such then roll your own similar formatting functions.
There is a small printf, integer only, and other formatting functions provided with prop-gcc. I'm not sure of the details having not played with it for a long while now.
The SPIN version of the interface library for Omnia Creator only takes about 4KB. The C++ version is highly variable depending on how much of it you use. Since it is a header only library only what you call is compiled into your code. Note that I'm pulling in floating point support on the Prop for a lot of the C++ demos to generate those pretty graphs.
I had been explaining to anybody, that couldn't get away, that arduinos are great for the flashing light stuff (and then did a remote control of a 3m dish using one ,sorry) but for the complete mind-melt, 8 cores are the minimum required. This IDE looks as though it will be the best of both ...
(As to where have been - I tried EMC but had to go back to cloud radiating, then moved house (smaller) and had nowhere but the concrete garage - which whilst a bit warmer than Heater.'s gaff not by much. Then a guy at work threw a guitar neck at me and challenged me to rebuild it - I built a couple after that with broken bits and I have been given a couple "proper" ones since. Just as with all of the micro controllers - I must get around to learning how to use them!. Now claiming a small corner of the conservatory, next to the bunny. I know my place)
A long time back I git hold of a 8051 board and was instantly disillusioned that a printf was too much for the free edition of Kiel. I see from those screen grabs that it takes 13K (opt 8K) on a Prop. What would the minimum, and type of, memory that would make this practicable (as in the sort of stuff that you guys managed to stuff into 32K before?
Seasons greetings
Alan
I've actually written a C++ version of printf that uses templates. It's extremely compact for the simple case (character string only) and relatively compact for the normal cases. I don't yet have a way to measure exact output size (I'm just using propeller-load's number) but it's 3.8 kB if no var-args are used. I think it goes to 5 or 6 with integer var-args and 9 with floating point support. The nice thing is - it's the exact same signature no matter if it's just a single character array, integer arguments, or floating point.
I messed up cogc support with the latest release. Please replace the propeller-cmake scripts in the ide/qtcreator/share/cmake-board-modules/propeller-cmake with the attached zip file contents. These updated files fix cogc linking issues. If you try to use cogc files without this fix they will not work.
Thank you for adding Spin support to Omnia Creator. I look forward to trying it out.
This last Black Friday, I ordered a couple of these Pololu Jrk 21v3 motor controllers. One of the selling points Pololu lists for these controllers is their configuration utility.
As you can see from the above picture, the utility graphs a bunch of the feedback from the controller. I'm hoping Omnia Creator can be used to create something similar with the Propeller when used with a h-bridge and encoders.
I'm hoping this sort of feedback will make tuning motor control algorithms a bit easier.
Based on what you've posted, it looks like Omnia Creator should make displaying this sort of information relatively easy.
Yes this would be awesome. Like you Duane I grabbed a couple of those 21jrk3's and linear actuators with feedback. They're nice in that they can accept commands from a variety of sources, but a prop would be even nicer as it could also present the information via a number of interfaces (omnia, serial terminal, vga, tv etc)
Thanks for the link to the parallax dual motor driver, wasn't aware of that one
Comments
@DavidBetz - I don't have the ability to build propeller-gcc. I depend on precompiled binaries. So, I don't have the default branch to test with.
@PhiPi - Almost done with a spin version of the interface library for the propeller. I just need to switch out the serial driver for my own custom driver with larger fifo buffers and add flow control code as required by my protocol. That said, I have a demo ready right now which works more or less. However, since flow control is not operational I've slowed down the update loop in the demo as to not overload the IDE. Additionally, without flow control bytes may randomly get dropped if they are coming in to fast or the computer is not servicing them. If you see an error about a corrupted packet just reset the board which will also reset the IDE's serial parser.
@Kye, your advice and provided files work fine at first look, understanding how OC parses and runs things like the board files, etc., helps a lot.
Sorry to be a pest but I cannot see a simple way to make OC fully detach from the USB serial port to the Prop without doing Board->Serial Port->(any other port or None). The reason I would like this functionality is that I use a PC based program to interact with the Prop as part of the entire project and the port isn't released from OC unless it's deselected. Changing the port in OC triggers a remake, as it should, but this causes quite a delay that wouldn't exist if the port could optionally just be released by OC after the code load and reopened by OC at the next load in the case of a user, like me, who doesn't need the serial terminal widget access.
Thx, Mike
I can also just make the cmake script faster. Manually determining dependencies via cmake for .spin and .cogc files is what takes so long. I read up on a way to make this faster which I think would help. I can post a new version of the build system tonight for this.
Thanks!
I'll mark this feature for the v0.3 release. I'll have that out by January. Until then, I'm going have a patch release out by Friday with all the bugs fixed that you've discovered along with a spin interface library.
Edit: Also, is there a way to enable line numbers to print along with the code? Perhaps Print Preview could be looked at as well? Please understand I'm NOT complaining or demanding in any way, just dropping train-of-thought ideas for potential improvement. As we all know all too well, the written word can very easily convey the wrong impression...
The code size mechanism kinda needs to support AVRs/PICs/etc. as well as the propeller. It makes more sense on the AVR because of that chip's Harvard architecture. Adding some more text to the compile output is an easy fix. However, for the GUI display I'll need a unified scheme. Right now since I'm using the third party Arduino-cmake build system I can't change it just yet. However, the Arduino-cmake build system is kinda abandoned so I'm going to have to roll my own. When that happens I can look at changing this up. What I have now is the best mechanism I could think of. The propeller really doesn't have data space per say... maybe I should just output code size and nothing else?
-Mike
https://github.com/omniacreator/qtcreator/blob/omniacreator/src/plugins/texteditor/basetexteditor.cpp#L290
https://github.com/omniacreator/qtcreator/blob/omniacreator/src/plugins/texteditor/basetexteditor.cpp#L344
https://github.com/omniacreator/qtcreator/blob/omniacreator/src/plugins/texteditor/basetexteditor.cpp#L308
However, printing is basically accomplished by the code manually drawing text on a page sized image and then sending that to the printer. I could probably get the feature working after a lot of trial and error but it is not easy. If you take a look at the code you'll see what I am talking about.
As for the image size stuff I made the data percentage now computed the same way as the code percentage. So, you can just add the two percentages to get the total space use now.
Additionally, I've also improved the build system to make it faster and more complete. You can now open .binary, .eeprom, and .elf files and load them along with improving spin and cogc file support.
Just unzip the attached files in the /ide/qtcreator/share/qtcreator/cmake-board-modules/propeller-cmake directory to update the build system for now.
You can add an external tool to Omnia Creator that will allow you to basically define a command line call with variables to do what you need.
Version 0.3 includes a lot of fixes for propeller support. Compiling C/C++ code for the propeller has no problems now and similarly compiling spin code works perfectly too. The CMake build system now does dependency checking for both cogc and spin source files (in addition to normal c/cpp files). This allows Omnia Creator to determine what spin files are part of your project and if things need to be rebuilt after changes to source files. Also, the CMake build system automatically supplies include directories to cogc and spin files now making it easy to pull in the Omnia Creator Interface Library into your spin code. Omnia Creator can also now open .binary, .eeporm, and .elf files and load them for you. A new SPIN error parser highlights the error line when a compile fails. A new propeller-load error parser will display a message box if loading fails too. Previously you had to look in the compile output to see what was wrong.
Here are some screen shots of what you can do with Omnia Creator in SPIN:
The Interface Library allows you to easily create numerous XY plot widgets and send data to them from your microcontroller. Widgets can be arranged around the main code window to create whatever debug interface you desire.
Though the graph interface you can easily display information about signals in your system. Additionally, taking the FFT of a graph has never been easier. Just execute one line of code to turn FFT's on. Feel free to edit this demo to change the data sources too! The built-in source is just a bunch of boring generated sinusoidals.
The bar chart feature allows you to create bar charts easily in Omnia Creator. This demo just shows off displaying sin waves using bar charts. There are much better uses for this feature... but, not many easily demo-able ones.
If you want to make statistical boxes that is easy too. But... it's not easy to make cool looking pictures out of them.
***
Omnia Creator v0.3 also includes two more spin demos showing off how to create multiple serial terminals and send text to them along with another demo showing how to use the built-in serial port the interface library supplies to receive regular text data from serial terminals while plotting to widgets at the same time. The interface library runs at 115200 baud when connected to Omnia Creator and has a 256 byte receiver fifo buffer.
Other things... if the interface library cannot connect to Omnia Creator or spends more than 5 seconds waiting for a command response from Omnia Creator it will automatically disable itself causing all function calls to immediately return. This means you can just leave the interface library calls in your code and after you disconnect your project from Omnia Creator you only have to pay a 5 second startup time penalty before everything works fine.
***
Caveats - CMake is not able to read UTF-16 files. This prevents the build system from being able to parse spin files and determine their dependencies and what files are in the project. Also long as your top object is not UTF-16 Omnia Creator will still work but will complain about sub objects that are UTF-16 not being part of the project if you try to edit them (Omnia Creator's editor can edit UTF-16 files). Also, the C/C++ build system will not compile the dat sections from spin files into your project if the spin file is UTF-16 because it can't read the file to determine if a dat section is present.
This issue will get fixed whenever CMake supports UTF-16 files. I opened a bug tracker with CMake about this. Hopefully they apply this fix for the next CMake release.
If you want to see the propeller font in your code go to the tools->options and change the editor font to the parallax font and the utf-16 symbols in your code will display correctly. The default font is courier which does not have the propeller font symbols.
This last Black Friday, I ordered a couple of these Pololu Jrk 21v3 motor controllers. One of the selling points Pololu lists for these controllers is their configuration utility.
As you can see from the above picture, the utility graphs a bunch of the feedback from the controller. I'm hoping Omnia Creator can be used to create something similar with the Propeller when used with a h-bridge and encoders.
I'm hoping this sort of feedback will make tuning motor control algorithms a bit easier.
Based on what you've posted, it looks like Omnia Creator should make displaying this sort of information relatively easy.
This looks fantastic!
Now I just need to find some time to try this out.
A long time back I git hold of a 8051 board and was instantly disillusioned that a printf was too much for the free edition of Kiel. I see from those screen grabs that it takes 13K (opt 8K) on a Prop. What would the minimum, and type of, memory that would make this practicable (as in the sort of stuff that you guys managed to stuff into 32K before?
Seasons greetings
Alan
Where on Earth have you been?
Personally I would forget printf. if you just want the functionality that is available in Spin with FullDuplexSerial and such then roll your own similar formatting functions.
There is a small printf, integer only, and other formatting functions provided with prop-gcc. I'm not sure of the details having not played with it for a long while now.
I had been explaining to anybody, that couldn't get away, that arduinos are great for the flashing light stuff (and then did a remote control of a 3m dish using one ,sorry) but for the complete mind-melt, 8 cores are the minimum required. This IDE looks as though it will be the best of both ...
(As to where have been - I tried EMC but had to go back to cloud radiating, then moved house (smaller) and had nowhere but the concrete garage - which whilst a bit warmer than Heater.'s gaff not by much. Then a guy at work threw a guitar neck at me and challenged me to rebuild it - I built a couple after that with broken bits and I have been given a couple "proper" ones since. Just as with all of the micro controllers - I must get around to learning how to use them!. Now claiming a small corner of the conservatory, next to the bunny. I know my place)
Alan
I've actually written a C++ version of printf that uses templates. It's extremely compact for the simple case (character string only) and relatively compact for the normal cases. I don't yet have a way to measure exact output size (I'm just using propeller-load's number) but it's 3.8 kB if no var-args are used. I think it goes to 5 or 6 with integer var-args and 9 with floating point support. The nice thing is - it's the exact same signature no matter if it's just a single character array, integer arguments, or floating point.
Yes this would be awesome. Like you Duane I grabbed a couple of those 21jrk3's and linear actuators with feedback. They're nice in that they can accept commands from a variety of sources, but a prop would be even nicer as it could also present the information via a number of interfaces (omnia, serial terminal, vga, tv etc)
Thanks for the link to the parallax dual motor driver, wasn't aware of that one