The above link has some discussion of "same function name twice in c++" from a Google search. There are several sites that discuss this. I just grabbed the one and have yet to really read it.
But it does start out with "function names do NOT have to be unique in C++....." argh.............
One way to think of functions in C & C++ is that they have a signature that is comprised of their return type, name, and parameters. C++ allows you to change the signature of a function without changing the name part. It's quite nice when used appropriately. C++ does have the limitation that you can't have two functions that only differ by their return type.
C and C++ can be quite confusing to the newcomer, but I will try to help you understand it a little better with a few points.
H files declare functions, variables, structures, etc....
C files are the main code that runs
INCLUDE allows you to include other files or objects in the file where you add the include, which can jump around alot from file to file. If you look, you will see that many files have the same INCLUDE to other files, that is because they all want the services or functions that a particular file or object has to offer. When you see a function being used in one file, but can't find a reference to it anywhere else, odds are that it is an included function.
Periods have a special meaning, with the part before the period being an object or structure, and the part after the period being a function or a structure member.
Functions can return a value or nothing at all. If they return nothing, it will say "void" in front of the function. If it says BOOL in front of the function, then it will return a 1 or 0 (TRUE or FALSE). It all depends on the type of return and there are many different types of returns.
In addition to returns, you can pass a function parameters or none at all. Some parameters may be required and others may not. Paremeters are enclosed in parentheses following the function name.
Functions begin with the return type, followed by the name, followed by the parameters, followed by the code that it will execute, with the code being enclosed in brackets { }
I could be wrong, but it almost appears as though F and S are unnecessary.
EDIT I mean S and P
S and P provide parameters which are context dependent... in some cases, S is for seconds and P is for milliseconds, in other cases S sets temperature in centigrade, P might have other uses. Generally if you provide code just for S, P can pretty much be a later update along similar lines if the Slice Compiler uses it. In some cases, there may even be an R for a temperature set for an inactive state.
It may be used and up to this point I have been unaware of it, but it is by no means a standard. If I have not seen it, I consider it RARE. I have numerous books on C and C++, and I have never seen it utilized in one of my books. I have spent countless hours reviewing C and C++ code and programs, and I have never seen it, so please don't tell me that it is standard.
Seems to be indexed in the texts I have under infinite loops and discussed under for( ). I guess I just read the wrong material. I have nothing to prove... just trying to be helpful. I merely presumed that Kernighan and Richie, " The C Propgraming Language: ANSI C " was standard ( pages 60 and 89 ).
We all learn something new everday... I guess for( ; ; ) is non-standard and I was presumtious.
I wonder what the proper standard infinite loop might be?
While looking up the answer, I came across the statement for( ;; ) again under Microsoft documentation, and it is definitely documented as an infinite loop. Like I said, I have looked at a lot of C and C++ code, and I just never seen it before. New one on me.
EDIT: However you will often see while(true) as Jazzed indicated
Well, while(true) is new to me, but language studies never seem to have just one right answer. Actually, while( ) will go infinited with any non-zero value and what I have seen is while(1). I suppose any other non-zero digit will work equally as well.
There are other ways to loop infinitely....... recursion, where the function name is called withing the statement. AND the nasty little goto that everyone tries to get rid of.
I'd have to say that for ( ; ; ), while(1), and while(true) are generally recognized as good form. The other means might be harded to notice and the loop stucture is not explicitly evoked.
As I said from the start, I am in this for the learning. SimpleIDE, C and C++ are all new challenges for me. And how to port an Arduino file, is yet another challenge.
Teacup is chock full of conditional compile directives that have to be pared back to just see the code, but I am making some progress. (and I really hate conditional compile directives! They seem like they are just there to guard the front door from people that want to learn how the code works.)
(and I really hate conditional compile directives! They seem like they are just there to guard the front door from people that want to learn how the code works.)
Overload !!!! I generally start out studying a topic with an introduction that is less than 100 pages; then I try reading something a few hundred pages long; and then work with reference tomes.
Starting with a giant book almost always gets me lost.
I started with an oldie C Tutorial by Kernighan (it actually enabled me to compare what PBASIC has with what C adds to PBASIC) and it is a 26 page read that I studied intently. PBASIC includes just about everything in the first 16 or so pages (I forget exactly where C adds new features, but finding this for yourself will be educationally empowering.)
From there, I got into the C classics
1. The C Programing Manual:2ed - ANSI C by Kernighan and Richie, c 1988
2. The UNIX Programming Environment by Kernighan and Pike, c.1984
For learning C in particular... it is all there in 3 good reference and the reading material is both short and clear.
A lot of later authors seem to publish books that pay by the pound and are too heavy to carry around to read on the bus and such. (I really believe that any 600-900 page tome should be cut up int 3 or 4 volumes so that one can read without the heavy lifting.)
C++ seems to have nothing short and concise published. I guess this is a hazard of the rise of the modern work processing software. You can't just get a quick read for an overview.
I would absolutely love to know of a C++ text that is less than 100 pages for new people to get started with... an overview provides a lot of the momentum to go further into the details.
Linux documentation seems to presume that you once read UNIX documentation. And yet most new C programmers have no idea or desire to study UNIX. So the UNIX Programming Environment is a real eye-opener. Everything is character-based programming (no GUI distraction), so it is clearer to see what the OS and the file system is trying to achieve.
Most of my C books are geared towards Windows and a GUI, except for "Writing Secure Code" and "C For Dummies", and all of my C/C++ books are outdated at this point, but they are still classics (til death do us part) .
It may be used and up to this point I have been unaware of it, but it is by no means a standard. If I have not seen it, I consider it RARE. I have numerous books on C and C++, and I have never seen it utilized in one of my books. I have spent countless hours reviewing C and C++ code and programs, and I have never seen it, so please don't tell me that it is standard.
The first time I saw for(;;); was in 1992 in some router startup code. The code started a bunch of threads and then just sat there doing nothing. I've seen it often over the last (OMG!) 22+ years.
Everyone has different experiences and expectations.
What is overload to Loopy is simple reference material to me ... reading a dictionary from cover to cover is not advised ... looking up beowulf is painless.
Okay, here is a bit of publishing history of the infinite loop in C.
I previously mentioned th 1988 text of Kernighan and Riche as it was in the index and the for( ; ; ) was mentioned while the while(1) [or while(true)] was not.
In the C Tutorial by Kernighan, circa 1974 that predates the above, BOTH the for( ; ; ) and while(1) are mentioned for creation of infinite loops.
Frankly I could care less about how hard the compiler works if the binary is the same thing.
It just seems that one or the other go in and out of vogue. As I mentioned earlier, languages tend to have more than one right answer. Perferred usage also changes over time. I was mostly referring to natural languages, but computer languages certainly have taken on the same thing. So one has to rely on a broader knowledge to grasp meaning from all comers.
There is a wee bit of rhetoric that leans in favor of for(;;) in The C Programing Manual:2ed - ANSI C, but I consider the whole question of which is best to be rather moot. You are going to see both. In the real world, I have to accept what the Brits speak and they have to accept what I speak. Rejection and imposing one's personal preferances as standard is hopelessly pedantic.
I must admit though that I am attracted to while(true), but the compiler probably prefers to handle while(1) AND not evaluate the true.
Regarding Teacup to Teacup-ette.
I am making progress through the .zip file. I have had to deal with getting rid of as must as I can of the conditonal compile code.
In fact I may have actually reached the end where mendel.c evolks a start of the code. (I am down to an error message of the that starting message).
The really nasty stuff it the PID code in heater.c. I plan to do away with PID to begin with as I suspect it is nearly impossible to port from the Arduino to the Propeller in any direct fashion. The code makes it even more awkward by have maybe 4 cases for different AVR chips and boards.
So we will start out with some simple hystersis control.
I have learned a lot about how to use SimpleIDE. I have trashed by Teacup port at least 5 times and had to start over because I realized I had made wrong assumptions. But there is light at the end of the tunnel. I am beginning to feel near to having something compile.
I have trashed by Teacup port at least 5 times and had to start over because I realized I had made wrong assumptions. But there is light at the end of the tunnel. I am beginning to feel near to having something compile.
Hi Brian,
Teacup is a bit overwhelming. But I keep chipping away at the files.
mendel.c has a huge amount of code that is abstracted to just intialize the i/o. At first I thought I 'd keep it, but it is so much easier to just charge out a Propeller i/o pin arrangement and write one 32bit long for Direction and another for initial states.
Conceptually, the code is very sophisticated with a Hardware Abstraction Layer to allow for all the various Arduinos out there. But since there is one and only on Propeller as the target it seems best to dump all that nonsense.
As it is now, I am a bit conflicted between keeping the Arduino library and the top most file that mimics Arduino's hiding of main. It seems to me that I can dump that top most file and still use the library for calls... then don't have any real relationship.
But I am muddling along and reading and researching a lot of questions.
I also have dumped the PID in the heater.c and will have to provide something else. That code is hugely architecture dependent. I begin to wonder who wrote this? I certainly do function at a very high level in the world of C.
Frankly, I feel a bit over my head and eating a lot of humble pie.
I wanted to say something yesterday, after reading this, but I held my breath, because I am normally an optimist:
Teacup is a bit overwhelming. But I keep chipping away at the files.
I am not the best C/C++ programmer, and there are many here that are much better than me, but on the other hand, I am no beginner either. After looking at the wide array of files belonging to Teacup, and all the different branches going here and there, I would be afraid to attempt following all that code. It would take a good deal of time to thoroughly understand that code and know where everything is.
When I first started learning C/C++, I had a concept and a goal that I wanted to achieve. Looking back now, it really was not all that difficult, but starting with no knowledge of C or C++, it was extremely difficult. I eventually conquered my objective, but I think your present goal is much harder than the one I started with. However I could be completely wrong, and it may just take various tweaks and settings.
However it turns out, I do not believe there is any need to eat humble pie. If you want to stick it through to the end, then do it. If not, just remember that all of us often underestimate the size of a given task.
That being said, I still think there is plenty of room to succeed in writing various software for 3D printing and the Propeller.
@IDBruce
Teacup code has some features that just play havoc with someone that pretty much avoids AVRs. Code that supports multiple processors with different registers for hardware resources and variation from 8 bit to 16 bit, and maybe even 32 bit processing inserts a lot of distractions.
The study is challenging, but it is informative as well. The whole process is a contrastive survey and may not be the most efficient way to write code for a 3D printer on the Propeller. My gut feeling is that I should take what I learn and write something entirely in PASM from scratch OR I should just take the G-code parser section and create the rest of the C code from scratch.
It would be nice to have an automated port from Arduino, but far too much of the condiitonal compile stuff is architecture dependent. So one has to not merely know Arduino programing, one has to have a relatively high degree of knowledge about AVR architecture of at least one chip.
++++++++++++++++++++++++
The goal remains to have a Teacup-ette binary for the Propeller, but just using Propelleruino libraries and tweaking a bit is not really reasonable with the original Teacup code as it was written for an array of multiple platforms and even a simulation on iOS
If a direct port is possible with the Propelleriuno libraries, I strongly suspect that one MUST first revise the code so that it compiles only for an ArduinoUNO.
In sum, all those conditional statement have to go! And by the time you get it down to an ArduinoUNO, you may have learned so much that the exercise of a direct port is pointless.
+++++++++++
Nothing wrong with trying something obviously foolish if one learns a better way. That may be the case here.
And so, I am comtemplatively regrouping, while reading up on a wide array of subjects that I need more background in. I got in this for the learning experience, and I am learning.
I really don't want to beg someone else to complete the goal for me as I won't learn much. I may fix Tonokip_with_serial along the way... if it will teach me something.
I do wonder how Bruce_B is doing as he has actually spent money on boards for this project. That is something I have tried to discourge from the start unless one has a good idea that they might have to blaze their own trail or use the boards for other things in other ways.
I do want to buy a PropellerASC+ and an XYZ stepper motor contorl board that plugs directly into it. But I haven't done so, so far............
The PropellerASC+ will easily port simpler Aduino code directly to support a wide variety of boards. XYZ CNC alone is a rather big challenge. When you add in 3D printing with thermal printer heads, the challenge is just that much more.
The bottom line... I'm learning C, C++, SimpleIDE, Catalina C, Propelleruino, ArduinoUNO, AVR architecture schemes, hardware abstraction layer constructions, Make and MakeFile, and a bit more.
And I am enjoying the learning. Nothing really is learned without some sort of naive ambition and quite a bit of perseverance.
Okay, well if you intend to go forward, then I will offer this advice:
When working on or altering someone elses project or code, I often print out hard copies and spread them out over a large area. Using hi-liters, I usually hi-lite area of interest, items to be removed, and items that deserve special attention, and of course using different colors for different purposes.
Considering that there are a lot of files, with a lot of text, that will be a lot of printing, but to me, examining hard copies with hi-lited areas is much easier to grasp and follow, as compared to going from file to file on the computer. Of course some may not like this method at all, but it always helped me. When I finally get around to digging deeper into these files. believe me, I will be printing out a lot of the code and hi-liting many areas.
If you have code that includes elaborate configuration for various Arduino platforms, it is likely best to get the code to compile for just one Arduino that is closest to what you desire (and can understand).
Then, cut away all the conditional compile language that relates to unused options. After everything is pretty much cleaned away, porting to a Propeller is likely to be much easier as you have merely one AVR architecture to compare against the Propeller architecture.
As it is, I have muddled along with knowing very much about any of the Arduino architectures and so the code being removed made little sense to me. By doing it this way, one doesn't have to know all and everything.
I guess I will have to start over with this procedure as the first step.
I have been following this post for a few weeks. I am a C programmer so I might be able to help some. I have been busy so I have had little time to help. I am trying to catch upwith you but I hit a snag.
I am getting errors when I compile that I think you guys can solve. I believe I saw reference to these issues somewhere. I hope that I have provided enough information.
I am using Windows 7 64-bit Pro -- maybe I need to use Linux -- I am trying to use SimpleIDE 0.9.45 and the included Propeller-gcc -- in SimpleIDE sub-directory
I did not add any environment variables to my path -- for now -- maybe this is part of the answer -- I do not see setup instructions -- still looking
I copied your code into a directory after I created a project and then:
I combined the header files into one file called firmware.h
I put the exact code from tonokip_with_serial(1)_without_kill.c in to a file called firmware.c
I did not modify your version of the files in the library or any of its sub-directories.
I have attached a JPEG image of my SimpleIDE project to show project hierarchy and Project Options -- in case that is error source
When I first built the source -- I got many of these --> error: unknown type name 'bool'
so I put the following in my firmware.h file
typedef enum { false, true } bool;
all 'bool' errors are gone
Now when I compile -- I get errors about PropellerASC, setup, and Serial --
I thought I saw a post in this topic that said something about preparing the libraries for use, which solves the "Serial" errors, at least
Why does my project not compile ?
Do I need one or more env vars for SimpleIDE or Prop-gcc ?
Do I need to specify a specific board ? You can see that the #define MOTHERBOARD 5 line is commented out in the header file (see image).
The Build Status window shows:
Project Directory: /ProjEng/FW/firmware/
propeller-elf-gcc.exe -v GCC 4.6.1 (propellergcc_v1_0_0_2162)
propeller-elf-gcc.exe -I . -L . -L library/libArduino/cmm/ -I library/libArduino -L library/libfdserial/cmm/ -I library/libfdserial -L library/libsimpletext/cmm/ -I library/libsimpletext -I /ProjEng/FW/firmware/library/libArduino -L /ProjEng/FW/firmware/library/libArduino/cmm/ -I C:/Users/alex/Documents/SimpleIDE/Learn/Simple Libraries/Text Devices/libsimpletext -L C:/Users/alex/Documents/SimpleIDE/Learn/Simple Libraries/Text Devices/libsimpletext/cmm/ -I C:/Users/alex/Documents/SimpleIDE/Learn/Simple Libraries/Text Devices/libfdserial -L C:/Users/alex/Documents/SimpleIDE/Learn/Simple Libraries/Text Devices/libfdserial/cmm/ -o cmm/firmware.elf -Os -mcmm -Wall -m32bit-doubles -fno-exceptions -std=c99 firmware.c -lArduino -lsimpletext -lfdserial -lArduino -lsimpletext -lArduino
In file included from firmware.c:6:0:
firmware.h:4:16: error: expected identifier before numeric constant
firmware.h:64:2: warning: #warning "PropellerASC not defined yet" [-Wcpp]
firmware.c:112:6: error: conflicting types for 'code_seen'
firmware.c:111:6: note: previous declaration of 'code_seen' was here
firmware.c: In function 'setup':
firmware.c:164:3: error: 'Serial' undeclared (first use in this function)
firmware.c:164:3: note: each undeclared identifier is reported only once for each function it appears in
firmware.c: In function 'get_command':
firmware.c:180:7: error: 'Serial' undeclared (first use in this function)
firmware.c: At top level:
firmware.c:216:13: error: conflicting types for 'code_seen'
firmware.c:211:13: note: previous definition of 'code_seen' was here
firmware.c: In function 'process_commands':
firmware.c:233:7: error: 'Serial' undeclared (first use in this function)
firmware.c: In function 'FlushSerialRequestResend':
firmware.c:425:3: error: 'Serial' undeclared (first use in this function)
firmware.c: In function 'ClearToSend':
firmware.c:433:3: error: 'Serial' undeclared (first use in this function)
Done. Build Failed!
Thank you Jazzed. I did download this but did not try it. I will do so.
Since posting my problems (#179 on 2014-05-02 at 7:51 PM EDT) I did re-compile the libraries on my PC by following your instructions that I located in this topic (#10 posted 04-06-2014 at 05:05 PM)
I had to comment out some lines in Serial.cpp -- basically making them stubs -- then all libraries -- libArduino libfdserial libsimpletext -- compiled with warnings -- creating both cmm and lmm -- in all three
Still getting warnings -- will keep working
Do you have further instructions that I have missed ?
Comments
I could be wrong, but it almost appears as though F and S are unnecessary.
EDIT I mean S and P
One way to think of functions in C & C++ is that they have a signature that is comprised of their return type, name, and parameters. C++ allows you to change the signature of a function without changing the name part. It's quite nice when used appropriately. C++ does have the limitation that you can't have two functions that only differ by their return type.
C and C++ can be quite confusing to the newcomer, but I will try to help you understand it a little better with a few points.
- H files declare functions, variables, structures, etc....
- C files are the main code that runs
- INCLUDE allows you to include other files or objects in the file where you add the include, which can jump around alot from file to file. If you look, you will see that many files have the same INCLUDE to other files, that is because they all want the services or functions that a particular file or object has to offer. When you see a function being used in one file, but can't find a reference to it anywhere else, odds are that it is an included function.
- Periods have a special meaning, with the part before the period being an object or structure, and the part after the period being a function or a structure member.
- Functions can return a value or nothing at all. If they return nothing, it will say "void" in front of the function. If it says BOOL in front of the function, then it will return a 1 or 0 (TRUE or FALSE). It all depends on the type of return and there are many different types of returns.
- In addition to returns, you can pass a function parameters or none at all. Some parameters may be required and others may not. Paremeters are enclosed in parentheses following the function name.
- Functions begin with the return type, followed by the name, followed by the parameters, followed by the code that it will execute, with the code being enclosed in brackets { }
Hopefully that helps a little.This is the first time that I have ever seen this one:
for (;;) { some code }What kind of loop is that? Comes from main() of mendel.c.
while(true) {
// do stuff
}
It may be faster/smaller depending on the compiler.
That's a new one on me.
That is a standard infinite loop in C or C++.
S and P provide parameters which are context dependent... in some cases, S is for seconds and P is for milliseconds, in other cases S sets temperature in centigrade, P might have other uses. Generally if you provide code just for S, P can pretty much be a later update along similar lines if the Slice Compiler uses it. In some cases, there may even be an R for a temperature set for an inactive state.
It may be used and up to this point I have been unaware of it, but it is by no means a standard. If I have not seen it, I consider it RARE. I have numerous books on C and C++, and I have never seen it utilized in one of my books. I have spent countless hours reviewing C and C++ code and programs, and I have never seen it, so please don't tell me that it is standard.
We all learn something new everday... I guess for( ; ; ) is non-standard and I was presumtious.
I wonder what the proper standard infinite loop might be?
While looking up the answer, I came across the statement for( ;; ) again under Microsoft documentation, and it is definitely documented as an infinite loop. Like I said, I have looked at a lot of C and C++ code, and I just never seen it before. New one on me.
EDIT: However you will often see while(true) as Jazzed indicated
There are other ways to loop infinitely....... recursion, where the function name is called withing the statement. AND the nasty little goto that everyone tries to get rid of.
I'd have to say that for ( ; ; ), while(1), and while(true) are generally recognized as good form. The other means might be harded to notice and the loop stucture is not explicitly evoked.
As I said from the start, I am in this for the learning. SimpleIDE, C and C++ are all new challenges for me. And how to port an Arduino file, is yet another challenge.
Teacup is chock full of conditional compile directives that have to be pared back to just see the code, but I am making some progress. (and I really hate conditional compile directives! They seem like they are just there to guard the front door from people that want to learn how the code works.)
Now that's funny
Overload !!!! I generally start out studying a topic with an introduction that is less than 100 pages; then I try reading something a few hundred pages long; and then work with reference tomes.
Starting with a giant book almost always gets me lost.
I started with an oldie C Tutorial by Kernighan (it actually enabled me to compare what PBASIC has with what C adds to PBASIC) and it is a 26 page read that I studied intently. PBASIC includes just about everything in the first 16 or so pages (I forget exactly where C adds new features, but finding this for yourself will be educationally empowering.)
From there, I got into the C classics
1. The C Programing Manual:2ed - ANSI C by Kernighan and Richie, c 1988
2. The UNIX Programming Environment by Kernighan and Pike, c.1984
For learning C in particular... it is all there in 3 good reference and the reading material is both short and clear.
A lot of later authors seem to publish books that pay by the pound and are too heavy to carry around to read on the bus and such. (I really believe that any 600-900 page tome should be cut up int 3 or 4 volumes so that one can read without the heavy lifting.)
C++ seems to have nothing short and concise published. I guess this is a hazard of the rise of the modern work processing software. You can't just get a quick read for an overview.
I would absolutely love to know of a C++ text that is less than 100 pages for new people to get started with... an overview provides a lot of the momentum to go further into the details.
Here is the link to the short C Tutorial by Kernighan that I feel is a great entry. Only 26 printed pages in PDF form.
http://www.lysator.liu.se/c/bwk-tutor.html
Linux documentation seems to presume that you once read UNIX documentation. And yet most new C programmers have no idea or desire to study UNIX. So the UNIX Programming Environment is a real eye-opener. Everything is character-based programming (no GUI distraction), so it is clearer to see what the OS and the file system is trying to achieve.
Everyone has different experiences and expectations.
What is overload to Loopy is simple reference material to me ... reading a dictionary from cover to cover is not advised ... looking up beowulf is painless.
I previously mentioned th 1988 text of Kernighan and Riche as it was in the index and the for( ; ; ) was mentioned while the while(1) [or while(true)] was not.
In the C Tutorial by Kernighan, circa 1974 that predates the above, BOTH the for( ; ; ) and while(1) are mentioned for creation of infinite loops.
Here is a link that claims the compiler has to work more with while(true) than with for(;;).
http://stackoverflow.com/questions/1401159/for-or-while-true-which-is-the-correct-c-sharp-infinite-loop
Frankly I could care less about how hard the compiler works if the binary is the same thing.
It just seems that one or the other go in and out of vogue. As I mentioned earlier, languages tend to have more than one right answer. Perferred usage also changes over time. I was mostly referring to natural languages, but computer languages certainly have taken on the same thing. So one has to rely on a broader knowledge to grasp meaning from all comers.
There is a wee bit of rhetoric that leans in favor of for(;;) in The C Programing Manual:2ed - ANSI C, but I consider the whole question of which is best to be rather moot. You are going to see both. In the real world, I have to accept what the Brits speak and they have to accept what I speak. Rejection and imposing one's personal preferances as standard is hopelessly pedantic.
I must admit though that I am attracted to while(true), but the compiler probably prefers to handle while(1) AND not evaluate the true.
I am making progress through the .zip file. I have had to deal with getting rid of as must as I can of the conditonal compile code.
In fact I may have actually reached the end where mendel.c evolks a start of the code. (I am down to an error message of the that starting message).
The really nasty stuff it the PID code in heater.c. I plan to do away with PID to begin with as I suspect it is nearly impossible to port from the Arduino to the Propeller in any direct fashion. The code makes it even more awkward by have maybe 4 cases for different AVR chips and boards.
So we will start out with some simple hystersis control.
I have learned a lot about how to use SimpleIDE. I have trashed by Teacup port at least 5 times and had to start over because I realized I had made wrong assumptions. But there is light at the end of the tunnel. I am beginning to feel near to having something compile.
I've got the same mess going.
Brian
Teacup is a bit overwhelming. But I keep chipping away at the files.
mendel.c has a huge amount of code that is abstracted to just intialize the i/o. At first I thought I 'd keep it, but it is so much easier to just charge out a Propeller i/o pin arrangement and write one 32bit long for Direction and another for initial states.
Conceptually, the code is very sophisticated with a Hardware Abstraction Layer to allow for all the various Arduinos out there. But since there is one and only on Propeller as the target it seems best to dump all that nonsense.
As it is now, I am a bit conflicted between keeping the Arduino library and the top most file that mimics Arduino's hiding of main. It seems to me that I can dump that top most file and still use the library for calls... then don't have any real relationship.
But I am muddling along and reading and researching a lot of questions.
I also have dumped the PID in the heater.c and will have to provide something else. That code is hugely architecture dependent. I begin to wonder who wrote this? I certainly do function at a very high level in the world of C.
Here is quote from you on another thread:
When I first started learning C/C++, I had a concept and a goal that I wanted to achieve. Looking back now, it really was not all that difficult, but starting with no knowledge of C or C++, it was extremely difficult. I eventually conquered my objective, but I think your present goal is much harder than the one I started with. However I could be completely wrong, and it may just take various tweaks and settings.
However it turns out, I do not believe there is any need to eat humble pie. If you want to stick it through to the end, then do it. If not, just remember that all of us often underestimate the size of a given task.
That being said, I still think there is plenty of room to succeed in writing various software for 3D printing and the Propeller.
Teacup code has some features that just play havoc with someone that pretty much avoids AVRs. Code that supports multiple processors with different registers for hardware resources and variation from 8 bit to 16 bit, and maybe even 32 bit processing inserts a lot of distractions.
The study is challenging, but it is informative as well. The whole process is a contrastive survey and may not be the most efficient way to write code for a 3D printer on the Propeller. My gut feeling is that I should take what I learn and write something entirely in PASM from scratch OR I should just take the G-code parser section and create the rest of the C code from scratch.
It would be nice to have an automated port from Arduino, but far too much of the condiitonal compile stuff is architecture dependent. So one has to not merely know Arduino programing, one has to have a relatively high degree of knowledge about AVR architecture of at least one chip.
++++++++++++++++++++++++
The goal remains to have a Teacup-ette binary for the Propeller, but just using Propelleruino libraries and tweaking a bit is not really reasonable with the original Teacup code as it was written for an array of multiple platforms and even a simulation on iOS
If a direct port is possible with the Propelleriuno libraries, I strongly suspect that one MUST first revise the code so that it compiles only for an ArduinoUNO.
In sum, all those conditional statement have to go! And by the time you get it down to an ArduinoUNO, you may have learned so much that the exercise of a direct port is pointless.
+++++++++++
Nothing wrong with trying something obviously foolish if one learns a better way. That may be the case here.
And so, I am comtemplatively regrouping, while reading up on a wide array of subjects that I need more background in. I got in this for the learning experience, and I am learning.
I really don't want to beg someone else to complete the goal for me as I won't learn much. I may fix Tonokip_with_serial along the way... if it will teach me something.
I do wonder how Bruce_B is doing as he has actually spent money on boards for this project. That is something I have tried to discourge from the start unless one has a good idea that they might have to blaze their own trail or use the boards for other things in other ways.
I do want to buy a PropellerASC+ and an XYZ stepper motor contorl board that plugs directly into it. But I haven't done so, so far............
The PropellerASC+ will easily port simpler Aduino code directly to support a wide variety of boards. XYZ CNC alone is a rather big challenge. When you add in 3D printing with thermal printer heads, the challenge is just that much more.
The bottom line... I'm learning C, C++, SimpleIDE, Catalina C, Propelleruino, ArduinoUNO, AVR architecture schemes, hardware abstraction layer constructions, Make and MakeFile, and a bit more.
And I am enjoying the learning. Nothing really is learned without some sort of naive ambition and quite a bit of perseverance.
Considering that there are a lot of files, with a lot of text, that will be a lot of printing, but to me, examining hard copies with hi-lited areas is much easier to grasp and follow, as compared to going from file to file on the computer. Of course some may not like this method at all, but it always helped me. When I finally get around to digging deeper into these files. believe me, I will be printing out a lot of the code and hi-liting many areas.
If you have code that includes elaborate configuration for various Arduino platforms, it is likely best to get the code to compile for just one Arduino that is closest to what you desire (and can understand).
Then, cut away all the conditional compile language that relates to unused options. After everything is pretty much cleaned away, porting to a Propeller is likely to be much easier as you have merely one AVR architecture to compare against the Propeller architecture.
As it is, I have muddled along with knowing very much about any of the Arduino architectures and so the code being removed made little sense to me. By doing it this way, one doesn't have to know all and everything.
I guess I will have to start over with this procedure as the first step.
I am getting errors when I compile that I think you guys can solve. I believe I saw reference to these issues somewhere. I hope that I have provided enough information.
I am using Windows 7 64-bit Pro -- maybe I need to use Linux -- I am trying to use SimpleIDE 0.9.45 and the included Propeller-gcc -- in SimpleIDE sub-directory
I did not add any environment variables to my path -- for now -- maybe this is part of the answer -- I do not see setup instructions -- still looking
I have downloaded your code: tonokip_with_serial(1)_without_kill from here http://forums.parallax.com/attachment.php?attachmentid=108220&d=1397899354 posted 04-19-2014, 05:20 AM
I copied your code into a directory after I created a project and then:
I combined the header files into one file called firmware.h
I put the exact code from tonokip_with_serial(1)_without_kill.c in to a file called firmware.c
I did not modify your version of the files in the library or any of its sub-directories.
I have attached a JPEG image of my SimpleIDE project to show project hierarchy and Project Options -- in case that is error source
When I first built the source -- I got many of these --> error: unknown type name 'bool'
so I put the following in my firmware.h file
typedef enum { false, true } bool;
all 'bool' errors are gone
Now when I compile -- I get errors about PropellerASC, setup, and Serial --
I thought I saw a post in this topic that said something about preparing the libraries for use, which solves the "Serial" errors, at least
Why does my project not compile ?
Do I need one or more env vars for SimpleIDE or Prop-gcc ?
Do I need to specify a specific board ? You can see that the #define MOTHERBOARD 5 line is commented out in the header file (see image).
The Build Status window shows:
Project Directory:
propeller-elf-gcc.exe -v GCC 4.6.1 (propellergcc_v1_0_0_2162)
propeller-elf-gcc.exe -I . -L . -L library/libArduino/cmm/ -I library/libArduino -L library/libfdserial/cmm/ -I library/libfdserial -L library/libsimpletext/cmm/ -I library/libsimpletext -I
In file included from firmware.c:6:0:
firmware.h:4:16: error: expected identifier before numeric constant
firmware.h:64:2: warning: #warning "PropellerASC not defined yet" [-Wcpp]
firmware.c:112:6: error: conflicting types for 'code_seen'
firmware.c:111:6: note: previous declaration of 'code_seen' was here
firmware.c: In function 'setup':
firmware.c:164:3: error: 'Serial' undeclared (first use in this function)
firmware.c:164:3: note: each undeclared identifier is reported only once for each function it appears in
firmware.c: In function 'get_command':
firmware.c:180:7: error: 'Serial' undeclared (first use in this function)
firmware.c: At top level:
firmware.c:216:13: error: conflicting types for 'code_seen'
firmware.c:211:13: note: previous definition of 'code_seen' was here
firmware.c: In function 'process_commands':
firmware.c:233:7: error: 'Serial' undeclared (first use in this function)
firmware.c: In function 'FlushSerialRequestResend':
firmware.c:425:3: error: 'Serial' undeclared (first use in this function)
firmware.c: In function 'ClearToSend':
firmware.c:433:3: error: 'Serial' undeclared (first use in this function)
Done. Build Failed!
Click error or warning messages above to debug.
Did you try this project? http://forums.parallax.com/showthread.php/155093-Porting-Arduinio-3D-Printer-code-(Teacup-firmware)-into-a-Propeller?p=1259283&viewfull=1#post1259283
Since posting my problems (#179 on 2014-05-02 at 7:51 PM EDT) I did re-compile the libraries on my PC by following your instructions that I located in this topic (#10 posted 04-06-2014 at 05:05 PM)
http://forums.parallax.com/showthread.php/155093-Porting-Arduinio-3D-Printer-code-(Teacup-firmware)-into-a-Propeller
I had to comment out some lines in Serial.cpp -- basically making them stubs -- then all libraries -- libArduino libfdserial libsimpletext -- compiled with warnings -- creating both cmm and lmm -- in all three
Still getting warnings -- will keep working
Do you have further instructions that I have missed ?