-
-
Notifications
You must be signed in to change notification settings - Fork 19.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HAL Rebased (preview merge against bugfix-1.1.x) #7028
Conversation
This is very good timing! It's time to move Marlin into the hierarchical file arrangement, and we're going to try and make that happen over the next week or so. At the same time, it would be excellent to have a working HAL for at least one 32-bit flavor in the first iteration. |
I think the most important thing is getting the HAL merged and maybe just the AVR platform, once that is stable adding other platforms is trivial (its why I split the commits like I did). There is still a lot to be done with the HAL cleaning up the api and splitting more things out, (multichannel spi, i2c) but if the HAL and AVR platform can be merged it should speed things up a bit. |
Do you need any assistance resolving conflicts or getting this to pass Travis? |
It's not an error I've come across before and seems to originate from the Teensy core, but I'll definitely look into it. Maybe I'll ask @PaulStoffregen if he knows what's going on. |
@thinkyhead It was able to merge for 5 minutes I think ^^, I'l rebase again soon. It is passing all the Travis tests for AVR, there just seems to be an issue with the Travis build environment for Teensy 32bit tests. |
It's actually building alright with Arduino IDE 1.8.3 and Teensyduino 1.37 beta on my W10 machine, but now I need to figure out how to get everything working again when installing everything headless from a Travis script. Looking into building the IDE from git currently. I was originally hoping there would be a way to install Teensyduino when headless but thus far I haven't seen a way to do it. |
It builds fine with Platformio aswell so I was pretty sure it was the Travis build environment that had an issue, I've only looked into it briefly but platformio is supported by Travis it could be easier to use that (or it could be worse), I'l need to get it working at some point for the LPC1768 tests. |
In the past the Arduino IDE has been the standard where everything has to compile, because that's the one a user is most likely to use. Changing this standard would probably deserve a discussion on its own and shouldn't be done just so we can get the tests to pass. I can't seem to be able to build the Teensyduino IDEs... |
I wasn't trying to imply you should take shortcuts to make this work, Platformio is just an automated way to install prerequisites and build projects across different (Arduino and otherwise) micro-controllers, so as Marlin diversifies it is one solution that could be looked at. This PR only includes Arduino based platforms so its not an issue yet. |
@p3p This is great news! I'm sure it is too much to hope for, but did you do this on a Re-ARM board? |
@Roxy-3D I did indeed use the Re-Arm although it will run on a smoothie board and mbed LPC1768 (with a very slightly different linker script and pinout), it is untested on an actual printer (the rewiring continues) but I have hooked it up to the reprap discount full graphic smart controller and have the lcd and sd (mostly) working, and it seems to be generating step pulses, I have ADC initialised and working though not on all pins. so overall its getting there. USB is quite far down the todo list so you need to use the hardware serial port on the Re-Arm and flash from a separate card reader. |
Hey, give it a try. It may end up being quicker at running the tests. I build exclusively with PlatformIO these days, and it does have some conveniences over the Arduino IDE. |
Well that sure was a quick discussion =) Would this then be the official direction? I'm asking if I should try to find a solution for the Arduino IDE, Teendyduino problems that are present here. If Travis will use PlatformIO in the future and normal non-headless compiling works okey, I'd then rather not spend time solving a problem that may not be there anymore. |
Fixed a cosmetic regression in nozzle.cpp I missed, rebased (this is my life now), and reverted 32bit Teensy Travis tests until the build system can be fixed. |
Well, ultimately we want to know that PlatformIO, Arduino IDE, and other IDEs can all build it. We're "officially" supporting IDE, command-line with |
When the time comes, can you give us all directions how to do that? There are a number of people here with Re-ARM boards. So if we can flash it, we can start getting the quirks taken care of. Who knows? Maybe in 3 or 4 months we will have an official 32-Bit version of Marlin running on LPC1768's ??? And from there... It can spread out like crazy. |
@teemuatlut Are you using a Re-ARM board ??? The more people with the exact same board will help things go faster. |
@Roxy-3D @teemuatlut is working on the Teensy 3.5 3.6 Platform which I think is mostly functional there was just an issue with the tests. The 32bit platforms actually have no effect on the HAL being merged and how complete they are really doesn't matter. I know the 32bit side of this is exciting but the focus needs to be on the 8bit AVR Platform and making sure its functionally identical to the current build. It really needs testing on AVR hardware. While I still need to rebase this practically everyday, and resolve all the merge conflicts each time, development is going to be slow as I'm reluctant to change much. Some help reading through the diffs and making sure I haven't missed any regressions or let anything stupid slip by would also be good, there's a lot to look through. |
I'm not sure when the lock down happens and the conversion starts. But I'm guessing a week. The thing is... Once that happens, the AVR stuff will be tested by 98% of the people using the code. The AVR testing will be almost automatic. The 32-bit people should be very careful not to break stuff for the 8-bit people, but there will be plenty of people to review the 32-Bit PR's and my guess is we don't have a problem.
I'll help as much as I can. Please @Roxy-3D me on any Pull Request. Even if it isn't one you did. If you see it is 32-Bit, let me know there is something to review. |
I'd like to but am currently not in a position to make too many new purchases. Has anyone worked on an STM32 based platform? |
I have done a bit of work on STM32F7, it's what I built my printer controller with, but I was using STM32 system workbench to build so it wasn't very user friendly to setup, and added another type of project file to Marlin so I intend to switch it to PlatformIO but I've changed focus to Re-Arm atm. |
I have an STM32F4-based control board running Marlin nicely through an older implementation of the HAL + a fork of the STM32Generic Arduino Core. I'm hoping to update it once the new HAL is merged, and I'd be happy to share anything from that once it's up to date. It's designed for an F446 microcontroller, but it shouldn't be too tough to use with any other F4. I have compilation + upload over USB working from inside the Arduino IDE at the moment, though I think only for Windows so far. Happy to share any more details if anyone else is trying to go down this path. Some sections of my HAL were originally based on @p3p's HAL work, so there's likely a bit in common between the two implementations. |
I can hardly wait for the 32-Bit HAL to be part of the main code base! |
Give me a shout when you need to test the Re-Arm. I have one on hand too. |
Implement AVR Platform
Using the Arduino eeprom api for other media types would be difficult and restrictive
I'm back from vacation and the Re-Arm was waiting in the mail :) |
One more thing I have been thinking about, and wonder if someone has done it already. |
Has anyone tried building a board to read the stepper out of other boards
to test if they are outputting the right signals?
While possible, I would think using an oscilloscope would be sufficient.
You could potentially monitor both an 8-bit and 32-bit board simultaneously
and see if they generate the same pulse patterns for the same movement
commands.
|
From my perspective... The real test is does it print? If it can move the nozzle in complicated patterns to finish a layer... And then it starts building right on top of the previous layer (and is correctly aligned), we have our answer!!! |
@Roxy-3D but if it doesn't move the nozzle in the correct manner, I can imagine connecting a logic analyzer, debugger... imagine if it doesn't stop the steppers at the end stop, or moves them past the limit, too fast. may be hard to know what exactly is going on if the steppers are erratic. |
@victorpv This isn't supported and .. never will be due to the way eclipse handles projects .. saying that all the compile options you need are in the lpc1768_flag_script.py file, setting up the environment is up to you. (This is what I use to develop, I set up with the Marlin repository wrapped in a eclipse CDT ARM project so I don't change anything in the repository ..) This only applies to the LPC1768 branch not this HAL PR, the platforms in this branch support the Arduino IDE. |
@victorpv - Miguel Sanchez' dcservo project could probably be commandeered to do that although I agree that a $5 logic analyzer or oscope would serve just as well. |
I've created a bugfix-2.0.x branch starting from the code in this PR, rebased to include today's merged PRs. Let's continue working on the HAL over there. Next thing, I'll merge the hierarchical file layout into We can continue to merge important bug fixes into the |
Do we have a thread to keep all the 32bit develpment discussion? |
No... not yet... But maybe we should start a new thread for 32-bit stuff.
Great! PlatformIO is less than intuitive. If you have problems with something, please don't struggle. Just ask! |
I suggest #7076 I found the command line PlatformIO quite easy to use. The GUI plugin and Atom... really not just a great experience at all, and I say that as a pro developer. |
I have not tried the command line PlatformIO. But the PlatformIO-IDE is not intuitive. |
It's a pity because they obviously put a lot of effort into the underlying
framework. I've used the Sloeber plugin for Eclipse (there is also a
pre-configured Eclipse) which works really nicely for Arduino projects.
There are a couple of Eclipse quirks to deal with, but otherwise I had no
problems.
There does seem to be a gap between something simple like Arduino IDE and
the nuclear option.
…On 1 August 2017 at 16:12, Roxy-3D ***@***.***> wrote:
I have not tried the command line PlatformIO. But the PlatformIO-IDE is
not intuitive.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#7028 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA7VR2XN-6J8CpOvv6-g8TnGs3xwhRY6ks5sT0BUgaJpZM4N2PYP>
.
|
I thought I read that PlatformIO can be installed into eclipse. Anyone know
if that's true?
|
And the real shame is it is only a couple of things that need to be 'fixed'. The first thing that needs some clean up is how you open a project. Originally, I wasn't even sure I had opened the project correctly. But then, once you have opened a project, it seems to be 'sticky' and even if you close the project and open another one, it seems the original project is what is getting built... |
Cool! Seems they support several editors, including Eclipse and Code:blocks. Code:Blocks might be more suitable as an alternative to Arduino IDE, it has less bells and whistles than Eclipse. |
@bobc have you used Sloeber to compile the LPC version? |
I used Sloeber with the Explore-M3 core to compile for LPCXpresso1768, I
haven't tried with the Re-ARM code.
…On 1 August 2017 at 18:24, victorpv ***@***.***> wrote:
@bobc <https://github.com/bobc> have you used Sloeber to compile the LPC
version?
I use sloeber all the time with the stm32 cores and love it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#7028 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA7VR_lGhmCpgH179J2lhH_tPO4A2Ghjks5sT19jgaJpZM4N2PYP>
.
|
I'm a casual bystander, and I'm considering making my own printer. I'd prefer marlin over smoothieware because of my familiarity and extensible of marlin (and RGB leds). Is marlin for re-arm something I should wait for or expect? Would I be better off just going with smoothieware at this point in time? |
Hi @Penagwin — Marlin 2.0.0 will be out within the next couple of weeks and will include Re-ARM support on par with Smoothieware. There's no harm in running Smoothieware in the meantime. |
@thinkyhead really appreciate what you all guys doing. Incredible dedication! I was gathering pieces of information together on when 32-bit marlin and list of supported platform will be available. Unfortunately, there is no one coordinated place where this info can be found ) This comment seems to be most fresh. It was 3 weeks ago. I wonder if anything has changed? |
I'm putting this here so hopefully there can be some testing on the 8bit AVR code in the HAL, it passes all Travis tests but that doesn't mean much. I've added a little to the HAL API to remove a few ifdefs but not much and spent a fair bit of time rebasing/regression checking but I need more people going through it, I will probably have missed (a lot of) things.
@teemuatlut do you have any idea what is causing the Teensy Travis errors? I checked your repository and they appear to be there aswell.
@Roxy-3D you may be interested in my LPC1768 branch its still very much a work in progress though, you will need platformio and to install this u8glib library, I'm still reconfiguring (making a mess of) my printer so I can integrate a ramps board for testing.