Porting Arduinio 3D Printer code (Teacup firmware) into a Propeller
LoopyByteloose
Posts: 12,537
I can only think of the adage that starts with "Only fools rush in..." in relation to doing this. But here goes.
The Teacup Firmware is intended for less that 32K code space, so I am beginning to attempt to port it over to the Propeller using the lib-Propelleruino that Martin H created last year.
Compile will be in GCC and the SimpleIDE.
I am very much in over my head on this as the code may require C++ skills (though it claims to be C) and I barely have C skills. Also, it is a very ambitious project for me.
So far I have made a tour of GITHUB and downloaded .zip files that are required. And I have installed SimpleIDE. I am just getting started.
Jazzed said he might help if I started this thread. It is premature for me to have any questions, I just need to open SimpleIDE and organize my files. So at this point, I am just introducting the project.
Feel free to comment or make suggestions.
The Teacup Firmware is intended for less that 32K code space, so I am beginning to attempt to port it over to the Propeller using the lib-Propelleruino that Martin H created last year.
Compile will be in GCC and the SimpleIDE.
I am very much in over my head on this as the code may require C++ skills (though it claims to be C) and I barely have C skills. Also, it is a very ambitious project for me.
So far I have made a tour of GITHUB and downloaded .zip files that are required. And I have installed SimpleIDE. I am just getting started.
Jazzed said he might help if I started this thread. It is premature for me to have any questions, I just need to open SimpleIDE and organize my files. So at this point, I am just introducting the project.
Feel free to comment or make suggestions.
Comments
Similar firmware that I've read use a timer to generate interrupts, and tend the steppers in the background. Meanwhile the foreground loop reads commands from the Uart and queues up movement commands for the interrupt task. Obviously the Propeller won't use a timer to poll an interupt service routine, but a cog will do the trick nicely. I did that when I ported the servo library and it worked like a charm.
The weak parts of libPropelleruino are I2C support (you won't need unless you read gcode off an eeprom), and the Arduino serial library for getting gcode from the serial port. The latter is fixable with a quick bit of work, I just used Propgcc's printf instead during my projects.
Thanks for offering. Since you originated the Propellerunio library, it is good to have you to turn to. I have read all 5 pages of your original thread for the sake of getting up to speed.
This porting will NOT try to target a particular Arduino shield. So the issues of holding to a certain pinout are minimal. But an ADC will be needed for monitoring the printhead temperature.
Regarding the timers and interrupts....
My main attention has been eslewhere in trying to find a verifiable "flavor" of g-code and a 32Kb or less programing size. Teacup firmware accomodates those desires.
But what you are saying is relevant as it seems the AVR use an interrupt service routine to drive the stepper motors at precise rates that an 3-D printer requires. Having to manage the heat and the feed of material into the printer head adds challenge beyond simple CNC movements.
I have been thinking of eventually revising the cog to one cog per stepper to get around the ISR approach on the AVR, but that is just an naive idea.
+++++++++
My current status is as follows:
A. Reading and studying the G-code parser front-end, the floating-point conversion to integer, and the code for the individual tasks as they are expected to be deployer for some overall background.
B. Learn where the Parallax F32 OBEX object might fit in or if the GCC floating point is adequate.
C. Create an understanding of how all the c files are linked together. I guess this will be some sort of tree diagram with one file at the head -- similar to what Spin does in a readme.txt file.
For some reason, C does not seem to automatically generate this (or I don't know how to do so). But the overview would really make me more comfortable.
+++++++++++
At some point soon I hope to do the obvious and just attempt a conversion without modification and without much understanding of the Ardunio code. While likely to fail, the error reports are likely to lead the way.
Out of the box C/C++ doesn’t build dependency trees. Although some IDE's have plug-ins that will do it. Generally I use a search command (e.g. grep) to find the main entry point and work downward from there. Arduino programs use setup and loop as the entry point.
Since Arduino uses C++ and Propgcc can compile C++ I think you're fine with floating point as the two platforms should have similar capabilities. You should strive to leave as much code in common as possible, and keep the platform dependencies in one place.
This will be an interesting project. It may be a little aggressive, but it should strengthen the Propeller-Arduino library.
Having Martin on board to help is a big win. Thanks to Martin for his contributions!
As Martin mentions, GCC has floating point built-in, so F32 is not necessary (curious that this idea has popped up).
I can spend a few hours a week helping with this. I think it's very important, but I have paying priorities too.
I'll explain the SimpleIDE linker later. Since Teacup has a makefile, it may be best to just use that ....
Thanks for starting this.
I have a 3d printer running marlin, I'll do what i can to help out. I've just started learning c and am very interested in seeing the propeller running a 3d printer.
Does prop c compile into assembly or does in compile into spin byte code ?
Brian
I do come onboard as a rather idiot-prone C programmer. So far I have been just trying to get the SimpleIDE open on my two main Linux machines - a desktop with LinuxMint (that I hope to use for slow compiles if that is the case), and an Asus EEEpc (that I carry about for study away from home).
The end product or crown jewel of this project would be to actually have a RepRap wiki entry for the Propeller board in its firmware listing and to have a GITHUB site established that provides a binary download of the completed project OR have the completed binary sit in Parallax OBEX -- which ever suit the Open Source legal environment.
I hope I am not being too grandiose. Meanwhile I plod on with just getting the SimpleIDE active. I thought I had it working on my AsusEEE, but seems I may have missed something.
have you read through the features of Teacup here: http://reprap.org/wiki/List_of_Firmware#Teacup
...
Has better performance due to
- written in C instead of C++
- only uses integer math
- minimizes long math interruptions
....
This should minimize some problems !!!
Only a suggestion:
What about using Tonokip instead of Teacup, it's also based on FiveD
has much less h-files/libs than teacup, has sd-card support and needs about 19KB code space (30K with SD)
https://github.com/reprap/firmware
Maybe this is an alternative for the beginning !
Christian
I am also using OpenSCAD in Linux for a 3D CAD design program. It has a lot of example files that can be fed into Slic3r to test actual code.
So everyone can use an all Linux set up -- OpenSCAD ==> Slic3r ==> into Teacup on a Propeller ==> into the actual printer.
+++++++++++++++
What about using Tonokip?
Well it sounds good, but I haven't identified a Slicer program to create g-code for it.
I'd welcome you doing that in parallel with Teacup if you really want it. I am sure Martin H and Jazzed are open to more ports.
I just chose something that seemed to offer an all Linux solution so there is no software cost for anyone working on developing.
I hope you understand my point of view.
There were some curious failures in that environment.
Martin, may I make the following suggestions so that the library works in the SimpleIDE context.
The SimpleIDE Auto-include context has some requirements (project links not necessary). I think Andy is writing a tutorial on creating libraries.
1. The Auto-include SimpleIDE library and header name have a tight relationship. When you do the #include "Arduino.h" SimpleIDE will look for a folder called libArduino.
2. The libArduino project must be compiled with CMM and LMM at minimum with Compiler 32bit-doubles and Linker Create Project Library checked.
I recommend this procedure with SimpleIDE in project mode for making a SimpleIDE libArduino library.
1. With the git command line window go to your SimpleIDE/Learn/Simple Libraries folder.
2. git clone https://code.google.com/p/lib-propelleruino/ libArduino
3. Go to libArduino and open the lib-propelleruino .side project with SimpleIDE
4. Save Project As libArduino
5. Build with CMM, then change Memory Model to LMM and build.
6. Change back to CMM, then quit or start a new project.
Make a blinky project.
1. Click New Project in SimpleIDE project mode.
2. Choose Documents/SimpleIDE/My Projects
3. Make a new folder Propellerino or something.
4. Type AbBlinker in the dialog and leave C++ selected.
5. Copy/Paste the code below in the AbBlinker.cpp file.
6. Click Load RAM and Run (Green right arrow).
/** * This is the main AbBlinker program file. * Blink Propeller ActivityBoard LED P27. */ #include "Arduino.h" void setup() { pinMode(27,1); } void loop() { digitalWrite(27,1); delay(50); digitalWrite(27,0); delay(50); }Will the Teacup library compile with the typical Arduino libraries that use C++ underneath?
It's pretty small
It also doesn't have some of the nicer Learn documentation in it.
Just download and extract the zip to some location, open with SimpleIDE then Load RAM and Run.
I'm working on taxes this weekend, but I might have a chance tomorrow.
The Arduino library is layered with wiring as the lower level, and then servo or stepper on top of that. If teacup uses some of the common libraries the port will go smoother.
Progress report. It seems I have SimpleIDE installed. For some reason that was a challenge for me. When it is installed in Linux, I didn't know you couldn't get it to run as a Superuser, but you do have to install it as a Superuser.
I also have managed to get the libPropelleruino recognized as a Project, not a Library.
No luck with getting the Arduino code recognized as anything at this point. My OS is Debian Linux.
Obviously, I need to spend time with the SimpleIDE user guide, but I have at least migrated the files in a directory that seems near to their final destination (in /home/SimpleIDE/...). I go elsewhere ( /Desktop/APPS/SimpleIDE to run it).
I also will be re-reading the above entries several times for whatever I may have overlooked.
+++++
It does seem that Martin H and Jazzed are verifying the 'what goes where, and how' with a Blinker file.
I may have to replicate that successfully before getting into the real stuff.
This is actually pretty clever and a good example of why a portable language like C is preferred by many engineers. It also means that retargeting this whole thing again shouldn't be that hard. Just create a third target for the Propeller and add conditional compilation blocks for it. This code could either call my libPropelleruino or be native Propgcc code.
The main entry point is in module mendal.c and it is the place to start to understand this code:
/// this is where it all starts, and ends /// /// just run init(), then run an endless loop where we pass characters from the serial RX buffer to gcode_parse_char() and check the clocks #ifdef SIMULATOR int main (int argc, char** argv) { sim_start(argc, argv); #else int main (void) { #endif init(); // main loop for (;;) { // if queue is full, no point in reading chars- host will just have to wait if ((serial_rxchars() != 0) && (queue_full() == 0)) { uint8_t c = serial_popchar(); gcode_parse_char(c); } clock(); } }I do understand what you are saying conceptually as I did see that the code was actually written for several processors other than the "328".
It would have taken me a long time to figure out that it wasn't really Arduino code in the normal sense. And it is both interesting and a bit awkward that it can be ported with or without the Propelleruino library.
It is awkward because it has helped immensely to have you involved. But there remains the question of which is the best goal - one, the other, or both?
And there are other considerations that come into play.
There is an alternative Arduino firmware that was mentioned, called Tonokip. It is very appealing as it included an SDcard. And including and SDcard was at some point going to become an issue.
My concern is I have no idea of how to prepare the g-code sub-set used by Tonokip to feed it. (Tonokip's parser would have to be recoded to conform to Teacup standards)
I don't have any Linux software that will just directly support it. On the other hand, it might be easier to modify the g-code parser to conform to Teacup than to add a SDcard front end to Teacup itself. Tonokip claims to be complete with a SDcard front end in 30Kb of code. It also may or may not be more rigorously Arduino code.
I do know that these mods to Teacup make more work.
They eventually had to be mentioned to deside to just do Teacup as it stands. I guess it expects to be fed g-code via a serial input. Or to enhance it to have the SDcard provide the file for printing.
I really hadn't expected your personal interest in this. Jazzed just said that he wanted to help out.
In sum, WE are still in an evaluation phase. WE can shift to an alternative porting source if it works out for the best. I may have just may a naive choice.
I think we need to soon get a concensus of what the final project should attempt to include. In this way, I suspect contributors would feel more comfortable that the project is not changing focus or expanding beyond what they feel good about contribuitng.
So please consider alternatives, such as:
A. Your own idea that I've possibly not heard yet
B. Keep with Teacup, possibly adding reading a g-code file from an SDcard
C. Changing to Tonokup, possible adapting its g-code parser to fully accept Teacup g-code with or without continuing to accept Tonokup's g-code format.
At this point I feel I am asking for far more than I really deserve to ask for. I am just about the least useful contributor to this project in terms of coding skills. Maybe it is mostly for me to provide a way to anchor down a good scheme.
Jazzed is welcome to provide input about A, B, and C as well.
Frankly, I'd like to see this project clearly demonstrate porting from Arduino code. I just may have provided the wrong candidate.
The only real issue that the zip I posted solves is that it is not necessary to add library paths to the project manager. All the user really needs is to have the libArduino folder either in the project folder or somewhere in the Simple Libraries folder. Most people who follow the Propeller-C Learn program will not know about adding things to the project manager. There are other complexities involved as well that I haven't had time to investigate.
I still owe something to Alice for this horrible mid-April junk. Better get it done now.
Thanks.
How I port software to a new platform is to pull all the modules into the new platform's build tools and let it rip. I then see a whole truckload of errors for missing functions or types. Hurry for progress! I then pick one function at a time and create do nothing stubs until it compiles clean. Hurry for more progress! Phase two is providing implementations for the stubs in the order that they are called. Often the rule of 80/20 kicks in and a small number of functions gets a system working well enough to do something useful.
I also like to defer decisions for as long as possible. For example in getting a clean compile I wouldn't care how I'll implement the functions in phase 2. That's a distraction that will slow down the goal of a clean build. I also try to change the source software as little as possible. The more changes you make the more debugging formerly working code you will do.
You'll learn a ton by porting software for both the source platform and the new target. You can also see how other people solve system organization problems in both good and bad ways.
Remember that a 30KB AVR program is an 8-bit program that runs on a C optimized instruction set. So, there is probably no way a 30KB AVR program will compile to 30KB on Propeller. It would be very interesting if it turns out to be smaller.
I wrote a G-Code interpreter in SPIN once for a CNC mill. I had room to do basic commands in the end, but finishing the interpreter would have taken much more effort. Here is a video of the Propeller G-Code interpreter running the X-Y table.
I realize that we are now in a discovery stage to determine whether there is a feasible worthwhile goal in this venture.
Getting 30Kb of code to directly port to the Propeller may indeed be impossible in that is 30K of machine code ( there are quite a few Structures included that seem to be data lookup tables) But with the SDcard, there may be alternative solutions.
Martin H. has already discovered an important fact.
>>> Porting Arduino code might run into code that doesn't originate on the Arduinio and may have been ported from elsewhere. Such code may be problematic or best handled without the use of the Propelleruino library.
+++++++++++++++
If at some point, the conscensus is that this project is not feasible as an attempt to port from Arduino to Propeller; I am willing to abandon it and move to an alternative project. I guess Martin H. might bow out at that point.
The alternative would just use Teacup as a g-code parsing reference. C might even be abandoned for a PASM intensive solution.
I would try to use the existing XYZ CNC code in OBEX and adapt that to the 3D Printer on the Propeller. My only involvement with the Teacup firmware would then be to transfer its g-code parser lexicon to the XYZ CNC code that exists so that I could use Slic3r to feed compiled g-code to it.
That object was intended for MDI (Manual Data Input) via a serial terminal. So once again the issue of adding an SDcard front end, plus a g-code parser come into play. It all ready includes an SDcard for other purposes. AND, it claims to have a flawed ring buffer on the output side.
+++++++++++++++++
I hate to wander this much and to pull up new alternatives, but this is a bit of a 'fact finding tour' at this point.
Even the XYZ CNC object that exists might need a complete makeover. There might be better ways to code it and the adding of a 4th stepper motor is needed for the printer head along with temperature monitoring and heat control. Reallocation of cog usage might be required.
************************
In sum, I don't expect youall to take up a lost cause. I respect your opinions and don't want to waste your time or just dump a project on you and run away.
I am at this time looking for guidance towards a feasible outcome of a 3D Printer on the Propeller that is fed data from SDcard files. The porting from Arduinio has always been a first attempt in the back of my mind.
I realize that this collaboration is based on everyone enjoying the project and getting something rewarding out of it for themselves. Feel free to come and go as you wish.
Not that my opinion matter's, but here it is. I've been playing around with cnc control for years and have looked at a lot of code for cnc control. I really don't think that you can do the propeller justice by porting a single processor code to the multicore prop. The propeller should really shine on motion control and should be written in assembly. Ken Bash has posted some really nice stuff on cnc control also.
Brian
Update: Where they do differ is in RAM which the Propeller has a great deal of, while most AVR's only have 2K.
In seems that Tonokit g-code is the same as Teacup.
Since Tonokit supports an SDcard and it has a much smaller code requirement without an SDcard, it may be more optimal to port one of its versions.
I am suspecting that the Tonokit firmward might actually work well to meld a Propeller SDcard object with an Arduino port.
And so, I am off to download and study Tonokit, post haste.
+++++++++++++++++
The reason for the sudden realization is that I started to read the front page of the Teacup firmware and the introduction says the following:
/** \mainpage Teacup Reprap Firmware
\section intro_sec Introduction
Teacup Reprap Firmware (originally named FiveD on Arduino) is a firmware package for numerous reprap electronics sets.
I was just not aware that FiveD and Teacup are the same g-code sub-set. I really want to have a clear connection to the software that compiles that g-code for this controller board to use.
Tonokit seems to be completely acceptable. Maybe even better than Teacup. (to be determined)
Be sure to use Arduino-IDE 0023 and not the newest 1.0.5 if you'd like to compile tonokip.
(at least on my system the newest Arduino-IDE does not compile tonokip)
That type of info is useful to Martin H.
Thanks Martin...
I will keep plodding forward. I can get Teacup to build, but immediately get errors due to Arduino dependences in the #include lines. So now I am struggling with how to get the libPropelleruion properly recognized.
You may have mentioned it before, but I may have missed it. [ NOTE - I certainly did miss suggestions, see #19 for how Martin H. wanted me to get started.]
At this juncture, it doesn't yet matter if I use Teacup or Tonokit as the dependences and inclusion of the Propelleruino library in a Build is the problem.
Since SimpleIDE has it's own methods of supporting a variety of Propeller boards, I am leaning toward the elimination of the existing MakeFile.
I have made some progress with including the libPropelleruino directory in the project, but uncertain if that is successful.
I am also wondering if the simpelide library conflicts with the libPropeleleruino.
Or you can register with the Teacup Firmware at GITHUB and get your copy directly.
Don't use this one ---> http://triffid.github.io/Teacup_Firmware/
This link is good...
https://github.com/Traumflug/Teacup_Firmware
I presume you meant Teacup which is listed with RepRap as an active firmware (under development)
Tonokip is listed as Abandoned or Depreciated firmware in RepRap, and it too has a GITHUB repository. I haven't acquired a .zip of its code as of yet. But it seems obvious that with successive generations of firmware, the source code continues to grow larger and larger.
https://github.com/tonokip/Tonokip-Firmware