I Admit Defeat
idbruce
Posts: 6,197
The time has come to throw in the towel.
I started the El Cheapo project with several goals in mind, which were:
1) Build a test platform for my linear actuators
2) Design my own extruder for 3D printing
3) Design a CNC controller using the Propeller chip
4) Learn
Result 1) Two of the three linear actuators have been buit, tested, and perform reasonably well.
Result 2) The extruder has been built and is impatiently waiting a trial test
Result 3) The controller has been built, but I doubt I will be using this to run the 3D printer, unless there is a worthy firmware developed for it.
Result 4) I suppose I learned quite a bit, but I sure did waste a lot of time.
As mentioned, the main goal has always been to create a test platform for my linear actuators. As it turns out, two have been ready for quite some time, but I have been bogged down by the pursuit of creating firmware to run my controller, and pursuing a Teacup port was a huge waste of time for me, that resulted in nothing but frustration.
I must move forward with my project, without wasting anymore precious time. As much as it pains me to say it, I am going to now take the easy way out, and run the Teacup firmware on the platform it was intended to run on. Perhaps I will someday return to this endeavor of creating firmware for the Propeller, but for now, I simply admit defeat.
Bruce
I started the El Cheapo project with several goals in mind, which were:
1) Build a test platform for my linear actuators
2) Design my own extruder for 3D printing
3) Design a CNC controller using the Propeller chip
4) Learn
Result 1) Two of the three linear actuators have been buit, tested, and perform reasonably well.
Result 2) The extruder has been built and is impatiently waiting a trial test
Result 3) The controller has been built, but I doubt I will be using this to run the 3D printer, unless there is a worthy firmware developed for it.
Result 4) I suppose I learned quite a bit, but I sure did waste a lot of time.
As mentioned, the main goal has always been to create a test platform for my linear actuators. As it turns out, two have been ready for quite some time, but I have been bogged down by the pursuit of creating firmware to run my controller, and pursuing a Teacup port was a huge waste of time for me, that resulted in nothing but frustration.
I must move forward with my project, without wasting anymore precious time. As much as it pains me to say it, I am going to now take the easy way out, and run the Teacup firmware on the platform it was intended to run on. Perhaps I will someday return to this endeavor of creating firmware for the Propeller, but for now, I simply admit defeat.
Bruce
Comments
Actually I am very sorry to hear this.
You probably know I gave up on Teacup sometime last year, and I also quietly abandoned trying to code a 3D printer solution in any form on the Propeller..
Why? Well, it is next to impossible to beat how much has been accomplished with the Arduinos. The user simply buys the board, load the software that has a long and glorious history of improvement, and it works. Starting over with the Propeller just has to be a work of love and passion. And 32K of Hubram really can't provide all and everything that has been added in the 256K RAM space of an Arduino MEGA.
In this case, the race was won by the swiftest and the most able to borrow from other sources in C.
+++++++++
Nevertheless, I have appreciated your reporting of struggles and breakthroughs as they have helped me understand a lot of the topics and issues that I struggle with and gave up sooner than you.
So all the discussion on the Forum has not been a waste of time. I still feel Teacup is about the only version suitable for 32K. And I strongly feel a lot of your insights are transferable to other ambitious projects. I repeat, nothing is really wasted.
I pretty much decided that this project would make a wonderful debut project for the Propeller 2. And I am simply waiting for that day. IN the meantime, I ponder how to work thorough the maze of Hardware Abstraction Layer code that Arduino uses. I don't particularlly think that HAL is good for new learners, maybe not good for any learner. Pruning code from the ATMega328 or ATMega2560 to migrate to the Propeller is daunting.
We all learn something from your contributions. Look forward to more.
A controller with appropriate software will certainly outperform one without software. This says very little about the hardware's performance.
I'm sure the Propeller is capable of controlling a 3D printer. I think David Saunders has previously used the Propeller to control a 3D printer and is in the process of rewriting his software in Spin.
I plan to control my CNC router with a Propeller.
Thank you for the very kind words. I just don't know how to respond to your comment , but to say thank you. It meant a lot to hear those words.
@David
As Loopy indicated, it is quite a maze indeed. I have worked on it for quite some time, studying the code pretty thoroughly, and I still don't understand it 100%, however I do understand it fairly well. Memory is just part of the issue, which of course is a very big issue. Besides the memory issue, I believe my biggest problem was trying to inject cog usage into the code, when it was meant to run on interrupts. I believe Dave Hein was correct when he tried to convince me to keep it single threaded, but without the use of cogs to act as the interrupts, it just isn't going to happen. In order for Teacup to work on the Propeller in any fashion, the application will need to act as a single threaded application, but using cogs to act as the interrupts. The real trick will be determining when to fire the cogs and when to stop them. I would imagine that someone with a well rounded knowledge of AVR architecture, the Propeller architecture, and C, might be able to achieve what I could not, but then they still have the memory issue to contend with.
Towards the end, I drilled the firmware down to what I consider a minimum, from a code stance, and that build came in at just a little above 31K. Okay so I am under threshhold, but that does not include stack space to run the cogs which may have very large sections of code to run. Additionally, it is my understanding that in order to produce quality prints, LOOKAHEAD must be enabled. The previously quoted 31K does not include LOOKAHEAD.
I am fairly confident, that by dissecting the code, and by eliminating substantial and important sections of code, a limited version of Teacup may fit, but who wants limited.
In the end, I think I had a pretty good idea about splitting the code in two and using two Propellers, but I soon discovered that the drawback of that plan was that there were actually two areas where processing was occurring. One area of processing was the at dda_queue and the other was at gcode_process. G1 moves were sent to the dda_queue, while all other items were handled by gcode_process. As mentioned, unless someone has intimate knowledge of the AVR architecture, this will be a very difficult obstacle to overcome.
On the other hand, if someone were brave enough to wiggle all the gcode_process stuff in to the dda_queue, then I believe two propellers would do the trick.
I suspect at some point, all this effort will be rewarded with discovering something extremely useful. We just don't know what that might be. It certainly will be fun to find out. Progress is not earned by being lazy and avoiding the difficult.
As I said before, the Hardware Abstraction Layer has really put me down. It seems that the manufacturers have specifically exploited this to make their C code branded product specific - and that blocks many projects from being ported from Arduino to Propeller. If you merely discover the key to that mystery, it will open many opportunities.
You may not even have to do much thinking. You have got a lot of other people thinking due to your tenacity.. I myself, am lazy. I merely try to help out in little ways.
I don't post a lot, but do read the threads (that interest me) daily. Not only have you created your own learning through this process, but have educated others in the process (myself included).
To coin an cliche':
"Life is not a journey to the grave with the
intention of arriving safely in a pretty and well preserved body,
but rather to skid in broadside, thoroughly used up, totally worn out, and loudly proclaiming -- WOW-- What a Ride!"
LOL Well that just about sums it up.
Thanks for the kind words Loopy and MrBi11
If you wish to adapt what I am posting a bit at a time, I would be honored. If not so be it.
The Propeller is way more capable than the Arduino, and a much better platform for controling a 3D printer. My 3D printer started with Raspberry Pi at its core, that did not work out. So I went with an AVR (ATMEGA32U4), that was a problem (even after spending almost a whole week developing the firmware).
Now my 3D printer has a Propeller at its core with working firmware. And I am rewriting the firmware from the ground up to make it better for others to use.
After some comments made this morning, I am going to be doing the rewrite in both SPIN and PASM. That is to say one version in mostly SPIN and a second version almost completely in PASM. Thus giving people a good choice. Yes it will mean double the testing for me, though it will be worth it to spread the use of 3D printers.
As to the extruder:
When I first built my 3D printer I did not yet have a working extruder (that took some time to make, as my lathe was tied up with other stuff). So I used a 3D Printing Pen, with a Servo to press the feed button, just using a fixed feed rate (as adjusting the feed rate would have required an extra servo). The 3D printing pen costs $50, more than making an extruder, though less than buying a ready made exrtruder.
I have my 3D printer sitting here, mostly built as a smaller modified 6mm version of the Prusa 2 and a J-head Mk V hotend (not yet fitted).
My hope was to find the time to get my Prop board working as a driver. But I couldn't find enough time so was hoping you would achieve and find a prop software solution.
However, a few months ago, I bit the bullet and bought the Arduino bits for a solution to get it up and running. But still no time to do this - perhaps I am not motivated enough without the prop, or really not enough time???
I do know that the prop is capable. Hopefully someone will achieve a solution eventually.
It's impossible.
There, that should do it.
I think it's a really neat project and it would be really cool to see it working. Besides, ask Erco how many flops he was involved in. :P
Admitting defeat and actually surrendering must not be the same to me, because I spent most of the day doing more research. Nearly twelve hours after making the initial post of this thread (several minutes ago), I came across this tiny paragraph, which gave me a different perspective of the Teacup source code.
Source: https://onehossshay.wordpress.com/
I just might give it one more try, with my new found perspective, but one thing is certain, the new perspective will not resolve the existing memory issues. And perhaps if I can nail it down to just the memory issue, perhaps that can be resolved with XMM.
Instead of porting teacup, all you need to do is deteremine what Teacup DOES that you want to do, and implement that. This is much different that what you took on.
Teacup takes G-code, and sends it to the printer. This is not so hard, take in a stream and send it out. the stream can come from a file, or it can come from the UI. This is not so hard.
The only interesting part is figuring exactly what Teacup is doing that you want/need to do. Investing a few hour in this analyis will turn into a few days, and possible a few weeks detening on how often you work at it,. But when the analysis is done, you will know exactly what you are doing, and it will be a simple matter of coding your requirements.
I'd say you learned a series fo vary valuable leassons, and are n the verge of a stunning success.
Is it that simple?
Heck no! If it was that simple, I would have been done weeks ago.
However, all we have to do it look at the teacup page on the reprap wiki for a very thorough list of requirements.
Section 4 in the index http://reprap.org/wiki/Teacup_Firmware#Design_Details_and_Tuning
lists the things we configure to use the firmware.
If you appraoch those items one by one, you might find each by itself is fairly simple. There are spin object for many of those already. For the tougher ones, just look in the source code to see what they are doing, and them implement it from scratch on the prop using the AVR source as a cheat sheet. ITs still a bunch of work, but must be easier than trying to get C code for the AVR to run on the prop.
But I don't actually know, as I am too lazy, and just used a stock sanguino to run the stock code. But this is I would do if I were to do it.
Maybe a compromise would be: http://www.mikronauts.com/raspberry-pi/robopi/
I dunno...
Teacup is designed to run on a smaller microcontroller. Much ifnot all that functionality should fit in the prop if its written properly. Anything that does not (larger than 32k memory needs, more than 32 io pins, etc) can be allocated to another processor, either the PC or a Raspberry Pi. Since we need a PC anyway, why not take that into consideration in the design? Yes, some printers have hardware to print from SD card in stand alone mode, but that tends to have problems and has not proven to be amandatory function, at least in the protype stage
As for future add-ons and expansion, consider avoiding this until the future when you actually have something working, and a demonstrated need for any addons or expansion. My 3D printer is perfectly fine exactly as it is, and all the "features" for add on and expansion are wasted. In particular the SD slot and the additional memory on the upgrade processor goes unused, only the faster clock is used. If I want more features I would build a new printer, the designs have evolved and improved in the last two years. If you start planning for every possible future, you end up wasting most of you time on stuff that will never be used as it will never come to pass. Better to stick to what you need right now, and do that well, and get it done.
Funny you should mention that.... I was just looking at some of the source code for linuxCNC this morning, and I must say that the code looks pretty darn complex. In addition to your comment, over the years I have read a lot of good things about linuxCNC, under their prior name. If I was attempting to run a serious piece of machinery, as in your case, I would most likely go that route, but I am shooting for a simple 3D printer, nothing fancy, just read from SD, print, and occassionally send a message to the LCD.
Teacup pretty much has everything I need, but I just can't seem to work around the interrupts. However Dave Hein says he has the solution, but I must not be doing something correctly with what he has put together.
I believe my port of Teacup is very close..... but like I said, those darn interrupts don't play well with the Propeller architecture. So now I am studying about interrupts, hoping to catch a glimpse of how I might be able to bypass my difficulties.
Yeah I know but you *can* break it down. I forget what method these guys used to get hard real-time from Linux and maybe that adds to the complexity. I did the same with Windows but that was courtesy of a timer interrupt incorporated in my encoder/DAC axis interface.
Interrupts only apply to single core devices so they don't exist in the Propeller.
I understand how interrupts work in the 6502 but other processors should be similar.
The 6502 has 2 types called IRQ and NMI which are Active-Low inputs.
IRQ or Interrupt ReQuest can be disabled (by setting the I or Interrupt bit in the Status Register) while NMI or Non-Maskable Interrupt can not.
A hardware device pulls either line low and that causes the processor to finish the current instruction and jump to the IRQ or NMI vectors.
A vector is a fixed memory location where the memory address for a piece of code is stored.
In the 6502 the vectors are at $FFFF-$FFFE, $FFFD-$FFFC, and $FFFB-$FFFA for RESET, NMI, and IRQ.
The code that is run for an interrupt is called an Interrupt Service Routine.
The 6502 does not know which device generated the interrupt so it must first check every device.
Most hardware has a register where interrupts can be enabled or disabled and another register which has the Interrupt Flag.
An Interrupt Flag is a bit that is set when an interrupt is generated.
The programmer knows which devices will be used along with their priority so the highest priority device is checked first.
If the device has multiple pieces of hardware then its Status Register needs to be checked to see what generated that interrupt.
When it found the device that generated the interrupt it would then run code to handle that device.
The 6502 has a command called RTI or ReTurn from Interrupt that would make it go back to what it was doing.
Here is the issue!
NMI has higher priority than IRQ and can not be stopped.
Imagine what happens when an IRQ is being serviced but an NMI is generated. Here we go again!
Also imagine that another device generates an IRQ while an IRQ is being serviced. It gets ignored!
So do you see the inherent problem with interrupts?
There is a balance between priority and timing.
Luckily this isn't an issue with the Propeller since each Cog can handle a different operation.
If it helps I have a simple C program that I wrote for a 68HC11 which uses an interrupt.
Porting hardware dependent code is a real bear, and it's made worse when the target platform is really different and has it's own limitations. Sometimes it takes a complete redoing of the code.
From what I've seen of the Teacup source code and reading it's wiki, even a port to a PIC32 or ARM is non-trivial.
I understand that and I am trying to explain that to Bruce.
Let's imagine a perfect world where you were able to create an interruptable Propeller. How fast do you think it will run? What kind of interrupts will it support? Of all the Arduino code out there that uses interrupts, how much of it only uses the interrupts supported by your new software? What perctange of that is not timing critical (because anything timing critical will not work with virtualized interrupts)? And finally.... with this limited scope of usability.... how many people are going to use this?
I hate being so pessimistic.... but I think you're going to find yourself with a complicated, slow piece of software with no audience.
And I thank you for your explanation.
In a nutshell, those three items are the ones that prevent us from accessing a lot of existing code. Being able to stop after an instruction and then restart with the next instruction. Or at least that is the way I currently understand it.