eboston
commented
9 years ago Is there a version for windows?
Closed thawkins closed 8 years ago
eboston
commented
9 years ago Is there a version for windows?
thawkins
commented
9 years ago Yes its supposed to work on all platforms, however you need a functioning python interpreter.
http://docs.platformio.org/en/latest/installation.html
There are full docs on making it work under windows, i will try it on my one windows machine tomorrow.
Im using a ramps card with a full graphic display as my test bed, as i have a spare set.
On Wed, Jul 29, 2015, 20:40 eboston notifications@github.com wrote:
Is there a version for windows?
— Reply to this email directly or view it on GitHub.
Wackerbarth
commented
9 years ago @thawkins -- You make a very good argument for the deletion of the Makefile. As for the supposed advantages of the scons build, the Arduino IDE will also do all of that once I convince people that we need to get rid of the 1.0.6 support.
As a Makefile replacement, I have few reservations. However, there are a few points that bother me. I assume that the python environment would not be an issue. (However, I do find it inconvenient that I cannot use python3.)
1) It is not obvious which version of the avr compiler tools is being used. 2) Similarly, what is the source of the avr "core" on which the build is based. (Can we easily control/replace it with one of our choosing? There are issues with the integration of Marlin with the current implementation of the serial ports) 3) As with the compiler, I wonder about avrdude. And what about support for boot loaders? 4) For many in our user base, the absence of a GUI is a drawback. Unfortunately, I think that many would-be users are unprepared to do much more that click a button, or two, in a GUI on a Windows-based PC.
thawkins
commented
9 years ago The makefile is adquate at the moment, but i was looking for something a bit better, the toolchains from platformio track the latest avr-gcc compilers and tools, im not 100% sure of how to determine the framework source versions. I would support removal of the Makefile so long as we maintain the platformio.ini file, and we provide howto docs to setup with platformio, and test it on windows and mac which i will try to do this week, I have access to all 3 platforms.
Both the makefile and platformio gives those of use who dont want to use the arduino system a mechanism that allows us to use professional ide's. Platformio takes it up a notch by supporting remote debugging on ecliose and netbeans, if you have a usb jtag interface.
Staying locked to the arduino toolset means the system build tools will never evolve, as i have already shown, platformio allows true libriaries with the advantage of being able to reduce program size through more efficient linking, this means more features can be fitted into 128k systems like printrboards etc (which platformio supports really well through its teensy platform support). Being able to organize and modualize the code using subfolders would be cool.
This same toolset supports the SAM and ARM processors, ARM6, 7 etc. If we do decide to put a hal in place its an ideal way of doing it.
The future of Marlin may not be arduino tools, they quite litteraly a millstone around the projects neck.
On Wed, Jul 29, 2015, 23:05 Richard Wackerbarth notifications@github.com wrote:
@thawkins https://github.com/thawkins -- You make a very good argument for the deletion of the Makefile. As for the supposed advantages of the scons build, the Arduino IDE will also do all of that once I convince people that we need to get rid of the 1.0.6 support.
As a Makefile replacement, I have few reservations. However, there are a few points that bother me. I assume that the python environment would not be an issue. (However, I do find it inconvenient that I cannot use python3.)
1) It is not obvious which version of the avr compiler tools is being used. 2) Similarly, what is the source of the avr "core" on which the build is based. (Can we easily control/replace it with one of our choosing? There are issues with the integration of Marlin with the current implementation of the serial ports) 3) As with the compiler, I wonder about avrdude. And what about support for boot loaders? 4) For many in our user base, the absence of a GUI is a drawback. Unfortunately, I think that many would-be users are unprepared to do much more that click a button, or two, in a GUI on a Windows-based PC.
— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/2544#issuecomment-125982125 .
Wackerbarth
commented
9 years ago On Jul 29, 2015, at 10:45 AM, Tim Hawkins notifications@github.com wrote:
The makefile is adequate at the moment, but i was looking for something a bit better
I am also …
But, the “millstone” is not the Arduino IDE, per se. Most of what you suggest below will also apply to the Arduino IDE 1.6.6+
My primary concern is that we be able to support the “click and shoot” user that knows nothing about real software development. (KISS)
There are also issues with the present Marlin codebase that make it incompatible with the latest versions of various components of the development tools. I know how to address that within the Arduino platform templates. (Like platformio, cmake, ant, etc. the Arduino IDE builds a “makefile”(or equivalent) and invokes the toolset.
, the toolchains from platformio track the latest avr-gcc compilers and tools, im not 100% sure of how to determine the framework source versions.
That’s an issue for me. unless I know exactly what is going into the build, can archive a copy of it, and control the version selected, I cannot use it.
I would support removal of the Makefile so long as we maintain the platformio.ini file
See the Platformio branch in my repository. Perhaps that will indicate a workable organization to accomplish it. There will then remain only two issues. (1) Can we avoid maintaining multiple build-configuration schemes? (2) If we drop using the Arduino IDE, how will we handle CI tests and how will we provide a simple “click and shoot” environment that is readily available to an unsophisticated user.
, and we provide howto docs to setup with platformio, and test it on windows and mac which i will try to do this week, I have access to all 3 platforms.
Mac is not an issue. All of my screens are on MacOS X. My Linux boxes run headless.
Both the makefile and platformio gives those of use who don't want to use the Arduino system a mechanism that allows us to use professional IDE’s.
I agree. However, those who are sophisticated enough to be able to use those tools can, almost trivially, reinvent the supporting configuration file.
Platformio takes it up a notch by supporting remote debugging on ecliose and netbeans, if you have a usb jtag interface.
Staying locked to the arduino toolset means the system build tools will never evolve, as i have already shown, platformio allows
Obviously you have not been following the development of the Arduino IDE. The current version already does much of that. And they are developing the infrastructure to handle the rest.
(Don’t get me wrong. We do need to get away from Arduino IDE 1.0.x and reorganize the code. But neither of those aspects are directly related to the choice of IDE support)
true libriaries with the advantage of being able to reduce program size through more efficient linking, this means more features can be fitted into 128k systems like printrboards etc (which platformio supports really well through its teensy platform support). Being able to organize and modualize the code using subfolders would be cool.
Both teensy and arduino/wiring have “issues” that need to be “worked around”.
This same toolset supports the SAM and ARM processors, ARM6, 7 etc.
The same is true of the current Arduino IDE.
If we do decide to put a hal in place its an ideal way of doing it.
Agreed.
The future of Marlin may not be arduino tools, they quite litteraly a millstone around the projects neck.
thawkins
commented
9 years ago I can have a go at the teensy stuff too, i have two printrboards stuck in my junk pile, i gave them up for ramps boards when ramps became ridiculously cheap, they are pain in the ass to update (requires dicking around with jumpers and reset buttons, which loses about 90% of joe public), are only 128k flash, and are very picky about the setup of the tools, in the printrbot community there is a preloaded hacked version of arduino 0.23, with the teensy mods already installed, which is the tool of choice for rebuilding printrboard Marlin. The printrbot version of Marlin also has hacked lcd menues, to keep it under the 128k limit. Thats why the platformio linking mechanism is of great interest, as it packs more functionality into the 128k flash.
They also use ceramic resonators instead of crystals for clocking, which for me in sub tropical philippines meant that the clock source for the usb interface was drifting all over the place with temp changes, and usb comms got flakey. One of them just plain stopped working when the temp went over 38c becuase the clock litteraly stopped. It was weird, the bot would slow down as it apporoached that temp like a clockwork toy at the end of a winding, then once the temp came back down, it would slowly wind up again. But by then the hotend had melted a big hole in the print and quite often the hotend had gone cold, and was glued to the print.
On Thu, Jul 30, 2015, 00:36 Richard Wackerbarth notifications@github.com wrote:
On Jul 29, 2015, at 10:45 AM, Tim Hawkins notifications@github.com wrote:
The makefile is adequate at the moment, but i was looking for something a bit better
I am also …
But, the “millstone” is not the Arduino IDE, per se. Most of what you suggest below will also apply to the Arduino IDE 1.6.6+
My primary concern is that we be able to support the “click and shoot” user that knows nothing about real software development. (KISS)
There are also issues with the present Marlin codebase that make it incompatible with the latest versions of various components of the development tools. I know how to address that within the Arduino platform templates. (Like platformio, cmake, ant, etc. the Arduino IDE builds a “makefile”(or equivalent) and invokes the toolset.
, the toolchains from platformio track the latest avr-gcc compilers and tools, im not 100% sure of how to determine the framework source versions.
That’s an issue for me. unless I know exactly what is going into the build, can archive a copy of it, and control the version selected, I cannot use it.
I would support removal of the Makefile so long as we maintain the platformio.ini file
See the Platformio branch in my repository. Perhaps that will indicate a workable organization to accomplish it. There will then remain only two issues. (1) Can we avoid maintaining multiple build-configuration schemes? (2) If we drop using the Arduino IDE, how will we handle CI tests and how will we provide a simple “click and shoot” environment that is readily available to an unsophisticated user.
, and we provide howto docs to setup with platformio, and test it on windows and mac which i will try to do this week, I have access to all 3 platforms.
Mac is not an issue. All of my screens are on MacOS X. My Linux boxes run headless.
Both the makefile and platformio gives those of use who don't want to use the Arduino system a mechanism that allows us to use professional IDE’s.
I agree. However, those who are sophisticated enough to be able to use those tools can, almost trivially, reinvent the supporting configuration file.
Platformio takes it up a notch by supporting remote debugging on ecliose and netbeans, if you have a usb jtag interface.
Staying locked to the arduino toolset means the system build tools will never evolve, as i have already shown, platformio allows
Obviously you have not been following the development of the Arduino IDE. The current version already does much of that. And they are developing the infrastructure to handle the rest.
(Don’t get me wrong. We do need to get away from Arduino IDE 1.0.x and reorganize the code. But neither of those aspects are directly related to the choice of IDE support)
true libriaries with the advantage of being able to reduce program size through more efficient linking, this means more features can be fitted into 128k systems like printrboards etc (which platformio supports really well through its teensy platform support). Being able to organize and modualize the code using subfolders would be cool.
Both teensy and arduino/wiring have “issues” that need to be “worked around”.
This same toolset supports the SAM and ARM processors, ARM6, 7 etc.
The same is true of the current Arduino IDE.
If we do decide to put a hal in place its an ideal way of doing it.
Agreed.
The future of Marlin may not be arduino tools, they quite litteraly a millstone around the projects neck.
— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/2544#issuecomment-126010339 .
thawkins
commented
9 years ago I should have added that platformio supports builds on multiple CI aystems, including travis.
On Thu, Jul 30, 2015, 00:36 Richard Wackerbarth notifications@github.com wrote:
On Jul 29, 2015, at 10:45 AM, Tim Hawkins notifications@github.com wrote:
The makefile is adequate at the moment, but i was looking for something a bit better
I am also …
But, the “millstone” is not the Arduino IDE, per se. Most of what you suggest below will also apply to the Arduino IDE 1.6.6+
My primary concern is that we be able to support the “click and shoot” user that knows nothing about real software development. (KISS)
There are also issues with the present Marlin codebase that make it incompatible with the latest versions of various components of the development tools. I know how to address that within the Arduino platform templates. (Like platformio, cmake, ant, etc. the Arduino IDE builds a “makefile”(or equivalent) and invokes the toolset.
, the toolchains from platformio track the latest avr-gcc compilers and tools, im not 100% sure of how to determine the framework source versions.
That’s an issue for me. unless I know exactly what is going into the build, can archive a copy of it, and control the version selected, I cannot use it.
I would support removal of the Makefile so long as we maintain the platformio.ini file
See the Platformio branch in my repository. Perhaps that will indicate a workable organization to accomplish it. There will then remain only two issues. (1) Can we avoid maintaining multiple build-configuration schemes? (2) If we drop using the Arduino IDE, how will we handle CI tests and how will we provide a simple “click and shoot” environment that is readily available to an unsophisticated user.
, and we provide howto docs to setup with platformio, and test it on windows and mac which i will try to do this week, I have access to all 3 platforms.
Mac is not an issue. All of my screens are on MacOS X. My Linux boxes run headless.
Both the makefile and platformio gives those of use who don't want to use the Arduino system a mechanism that allows us to use professional IDE’s.
I agree. However, those who are sophisticated enough to be able to use those tools can, almost trivially, reinvent the supporting configuration file.
Platformio takes it up a notch by supporting remote debugging on ecliose and netbeans, if you have a usb jtag interface.
Staying locked to the arduino toolset means the system build tools will never evolve, as i have already shown, platformio allows
Obviously you have not been following the development of the Arduino IDE. The current version already does much of that. And they are developing the infrastructure to handle the rest.
(Don’t get me wrong. We do need to get away from Arduino IDE 1.0.x and reorganize the code. But neither of those aspects are directly related to the choice of IDE support)
true libriaries with the advantage of being able to reduce program size through more efficient linking, this means more features can be fitted into 128k systems like printrboards etc (which platformio supports really well through its teensy platform support). Being able to organize and modualize the code using subfolders would be cool.
Both teensy and arduino/wiring have “issues” that need to be “worked around”.
This same toolset supports the SAM and ARM processors, ARM6, 7 etc.
The same is true of the current Arduino IDE.
If we do decide to put a hal in place its an ideal way of doing it.
Agreed.
The future of Marlin may not be arduino tools, they quite litteraly a millstone around the projects neck.
— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/2544#issuecomment-126010339 .
Wackerbarth
commented
9 years ago On Jul 29, 2015, at 11:58 AM, Tim Hawkins notifications@github.com wrote:
I can have a go at the teensy stuff too, i have two printrboards stuck in my junk pile, i gave them up for ramps boards when ramps became ridiculously cheap, they are pain in the ass to update (requires dicking around with jumpers and reset buttons, which loses about 90% of joe public), are only 128k flash, and are very picky about the setup of the tools, in the printrbot community there is a preloaded hacked version of arduino 0.23, with the teensy mods already installed, which is the tool of choice for rebuilding printrboard Marlin. The printrbot version of Marlin also has hacked lcd menues, to keep it under the 128k limit. Thats why the platformio linking mechanism is of great interest, as it packs more functionality into the 128k flash.
My concern is in finding, and configuring, the various “tool” pieces. For example, it appears that some AT90USB1280 based boards are distributed with an AVR109 bootloader. I guess that it works for some, but I couldn’t get it to work with avrdude on my Mac. (I flashed a HID/halfkay bootloader instead. In that configuration everything works OK) But I really want to get away from the Teensy pin numbering. These boards have no TPs associated with that labeling scheme and supporting multiple ARTIFICIAL pin numberings (they don’t have Arduino pins either) is a PITA.
They also use ceramic resonators instead of crystals for clocking, which for me in sub tropical philippines meant that the clock source for the usb interface was drifting all over the place with temp changes, and usb comms got flakey. One of them just plain stopped working when the temp went over 38c becuase the clock litteraly stopped.
I haven’t hit THAT issue. 38c is “everyday” here (if it doesn’t reach 40) at this time of the year. But then I don’t run the printer outdoors.
jbrazio
commented
8 years ago Thank you for your interest making Marlin better and reporting this issue but this topic has been open for a long period of time without any further development. Marlin has been under heavy development for the past couple of months and moving to it's last mile to finish the RC cycle and release Marlin v1.1.0. We suggest you to try out the latest RCBugfix branch and reopening this issue if required.
github-actions[bot]
commented
2 years ago This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Platform.io is an advanced build system generator for AVR (and SAM aand ARM and PIC etc) embedded projects. It creates make, cmake and other build files and can create project files on multiple platforms, multiple targets for multiple IDE's including VS, cLion, Eclipse, Netbeans
The following is a transcript of building Marlin on a machine with no marlin source, no arduino, no avrdude, no compilers or tools, the Configuration is set for RAMPS_EFB single extruder and REPRAP_DISCOUNTFULL GRAPHIC_CONTROLLER in the transcript.
The platformio file that needs to be maintained is tiny (platformio.ini) and the system has a built in package manager that makes downloading and installing the U8Glib library needed for the graphic Controller a breeze.
Note the following at the bottom of the transcript
its created real libraries out of the arduino libraries and the U8GLib library, and is linking them instead of just including them in the compilation as the aurduino system does. This means if a source file is not needed it is not linked, this is particularly nice for programs using the graphics libs and the resulting program is about 5-10% smaller