The Marlin 2.0 32-bit thread

[thinkyhead]

Board	MCU	State	To-Do
8-Bit AVR boards, RAMPS, etc.	Arduino AVR	💚good
Due, RAMPS FD (v2.A!), etc.	SAM3X8E	💚good
Duet Wifi + X5	SAM3X8E	❓unknown	E3D Toolchanger on hand
Duet 2 Maestro	SAM3X8E	⚠️beta
Archim 1.0	SAM3X8E	❓unknown	Only US$170!
Archim 2.0	SAM3X8E	💚beta	needs confirmation
Grand Central	ATSAMD51	🛑tbd	(RAMPS_FD shield should work)
Re-ARM	LPC1768	💚beta
MKS-SBASE	LPC1768	💚beta
Smoothieboard	LPC1769	💚beta
Azteeg X5 GT	LPC1769	💚beta
Cohesion3D Remix	LPC1769	💚beta
Selena Compact	LPC1768	💚beta
Malyan M200	STM32F103C8	💚beta	EMERGENCY_PARSER,NEOPIXEL_LED, etc.
Borg	STM32F765ZGT6	⚠️beta	EMERGENCY_PARSER,NEOPIXEL_LED, etc.
Chitu3D V3.9	STM32F103ZET6	🛑alpha	EMERGENCY_PARSER,NEOPIXEL_LED, LCD, SDCard, MAX6675, etc.
Teensy 3.5	MK64FX	⚠️beta	(need shields)
Teensy 3.6	MK66FX	⚠️beta	(need shields)
Espressif 32 Wifi	ESP32	⚠️beta	(mostly working?)
STEVAL-3DP001V1	STM32F401VE	🛑alpha	(need boards)

• Good: All features working.
• Beta: All features implemented, mostly working.
• Alpha: Some features unimplemented/broken.

---

This thread is for discussion of 32-bit issues needing work and coordination of the 2.0 release.

[Roxy-3D]

It's not easy to stop the flow of issues, and we want to keep fixing any bugs that exist in 1.1, of course. So I propose that we take care of the current crop of obvious bugs —and only bugs— do a 1.1.4 release very soon, and one more release —1.1.5— just before we release 1.2.x, the new hierarchical + HAL version of Marlin.

@Tannoo and I have some clean up work going for the LCD header files. As it turns out... The .h files can only be included by one .cpp file because the .h files generate code. While this is not a 'bug fix' it is an important item from a 'code cleanliness' perspective.

We have the Graphical LCD Display code clean up done. The 20x4 LCD Display clean up should progress quickly. https://github.com/Tannoo/Marlin/tree/ultralcd_impl_DOGM.cpp

[Tannoo]

https://github.com/Tannoo/Marlin/tree/LCD_Interactive_Mesh_Edit_Refinements

[teemuatlut]

Release 1.2 (or Marlin 2.0?) with the hierarchical layout, support for some 32-bit boards.

Go with v2.0. Support for 32bit platforms will indicate a new era for Marlin and for sure will warrant a tick in the major version count.

[Roxy-3D]

We have the Graphical LCD Display code clean up done. The 20x4 LCD Display clean up should progress quickly. https://github.com/Tannoo/Marlin/tree/ultralcd_impl_DOGM.cpp

Both the Graphical LCD Panel and the 20x4 LCD Panel .h files are cleaned up in this branch...

Tannoo is going to get the indentation and white space cleaned up....

[thinkyhead]

The .h files can only be included by one .cpp file because the .h files generate code.

That is correct. The LCD-oriented header files may only be included once, and only in ultralcd.cpp. They are essentially just .cpp files, but given .h extensions so that they don't compile outside of ultralcd.cpp.

We could make them into proper .cpp files and fix the unorthodox usage, without any negative affect on performance, but let's wait till @Tannoo's changes are ready.

[ImplementOfWar]

Is the new file structure going to allow Marlin to use a single file for Configuration? Much like Smoothieware? Is that one of the immediate benefits of doing this, apart from 32 bit and HAL ?

[thinkyhead]

@ImplementOfWar That has not been discussed yet. Smoothieware is able to do certain things by limiting itself to 32-bit boards which have far greater resources. When and if someone implements a configuration system in emulation of Smoothieware, it will have to be for 32-bit boards only.

[Roxy-3D]

@thinkyhead What are you thinking for a time table to lock down the code?

I thought I could get the ultralcd_impl_HD44780.h separated into declarations and code generation... But it is turning out to be worse than I expected. We have the DOGM stuff separated, so that is a start. But the 20x4 LCD code is especially bad. It is very very ugly...

So, we could just go with what we have... Or... You can take a look at where we are at: https://github.com/Tannoo/Marlin/tree/ultralcd_impl_DOGM.cpp and see if you can figure out the issues?

[Tannoo]

You can take a look at where we are at: https://github.com/Tannoo/Marlin/tree/ultralcd_impl_DOGM.cpp

https://github.com/Tannoo/Marlin/tree/LCD_Interactive_Mesh_Edit_Refinements

[Tannoo]

I should delete the ultralcd_impl_DOGM.cpp branch. It was created as a test bed for the splitting of the DOGM.h file.

[petrzjunior]

We should probably ping the whole @MarlinFirmware/language-team to complete translations.

[fixoid]

Do I understand correctly that the new features will not be added before the release of version 2.0 (1.2)? If so, when can we expect 2.0? What about PRs that were created before the decision was made?

[Roxy-3D]

What about the PRs that were created before the decision was made?

In general... The Pull Requests generate for the current organization that do not make it into the new file layout should not be that difficult to regenerate. The bulk of the files are not going to change. What may change are things like paths to header files or stuff like that. If your Pull Request doesn't make it to the new layout automatically... It will be very straight forward to regenerate it.

[thinkyhead]

thought I could get the ultralcd_impl_HD44780.h separated into declarations and code generation... But it is turning out to be worse than I expected.

The ultralcd_impl_* files were never designed to be standalone, but are really just split out parts of ultralcd.cpp. It would be best to wait till the ultralcd code is converted to a singleton class, and rearrange anything needing rearranging at that time. It will make more sense once it's examined in terms of a class — and ultralcd_impl_* may end up as two instances of a helper class. Or there may be other separation of functionality into more classes. It's something I want to work on more comprehensively, immediately after rearranging the code and getting the HAL working. And I'm pretty sure the LCD menu code can be simplified somewhat also.

[thinkyhead]

Do I understand correctly that the new features will not be added before the release of version 2.0 (1.2)?

Halt means halt. If a larger number of contributors would like to help get the existing PRs merged, that would be an excellent change of pace. There's a lot of backlog to take care of.

If so, when can we expect 2.0?

As soon as I can get it together.

What about PRs that were created before the decision was made?

There's nothing to be done about it. There will never be some point in time where every PR will be merged, so it's best to stop the flow of new PRs and work on the PRs that we already have in front of us. I have been trying to get as many merged as possible, but more keep coming in. And so, we just have to go for it and it's just unfortunate timing for any PRs that will need to be reworked.

As it is, it will be me who has to re-work all the existing PRs into the new layout, because I have the mojo to make that happen as quickly as possible, and I will have all contingencies freshly in mind.

[thinkyhead]

What are you thinking for a time table to lock down the code?

Let's keep fixing bugs all the live long day. Simply don't merge new stuff, and put off new features. If any new features come in while we're working on the transition, we'll simply put them off. Most contributions will be straightforward enough that it will be easy to re-make them for the new layout. Some we may have to work on within the old layout first, then when ready also bring them to the new layout.

We should continue to fix bugs in the 1.1.x branch and I will make sure they are brought into the new layout as well.

As for a timetable, I think we need to go in two stages. First, since we have so much work being done to make the 32-bit code ready, perhaps we should get that into minimal working shape first. Then I can include a genuine HAL as part of the initial 2.0.x branch.

The layout conversion itself isn't hard. The first conversion will take me less than a day to complete, and then we can go over it and see where it needs tweaking.

I'd like to focus on going over the open issues for the next day or two, patch up as many obvious bugs as possible, and merge as many of the lingering PRs as possible. One of PRs contains the 32-bit HAL rebased on the latest bugfix-1.1.x and that will also need to be brought up to date — though not merged with any Marlin 1.1.x.

Once the HAL is working and we're happy with it, then I'll rebase it onto the latest code and use that as the starting-point for Marlin 2.0 with the new file layout.

I think it's a good idea to take the next few days and close as many issues as we can so we have a fresh start.

Yes, it's possible that we could have a 2.0 layout and initial release by the end of the week… but let's loosen up the schedule so we can clear as many issues as possible and just aim to have it ready by July 1. How does that sound?

[Roxy-3D]

Yes, it's possible that we could have a 2.0 layout and initial release by the end of the week… but let's loosen up the schedule so we can clear as many issues as possible and just aim to have it ready by July 1. How does that sound?

July 1st sounds fine... Especially if there is a sample 32-Bit HAL limping along and able to move the nozzle around!!!

[p3p]

@Roxy-3D I'm pretty sure all the platforms currently in the HAL can do that, if the board supports the Arduino framework it's fairly trivial to implement basic features, the main stumbling block for non Arduino framework devices is the extra features needing Arduino libraries or Classes. I should be able to print tonight on my Re-ARM but the HAL needs further extended to strip all Arduino based features out of the main code and behind an API this will need to be done incrementally once we get the HAL merged.

[Roxy-3D]

I should be able to print tonight on my Re-ARM but the HAL needs further extended to strip all Arduino based features out of the main code and behind an API this will need to be done incrementally once we get the HAL merged.

What classes and functions are you missing? Would it be possible to just pull in the Arduino libraries so we don't have duplicated code complicating things?

[p3p]

Things like Print and Wire (as two random examples), just generally anything that is from the Arduino framework will need to be abstracted, this won't lead to code duplication and should lead to much cleaner and more understandable code, anything that can use the Arduino framework still can, although sometimes it may turn out it wasn't even necessary just convenient when it was implemented.

In some cases it may be difficult without introducing some indirection overhead, but anything performance critical already avoids the Arduino framework. It may be a good idea to have folders in the HAL (arduino_framework, mbed_framework) devoted to anything that can be reused among platforms that use that framework, but that's probably discussion for another day.

[Roxy-3D]

It may be a good idea to have folders in the HAL (arduino_framework, mbed_framework) devoted to anything that can be reused among platforms that use that framework, but that's probably discussion for another day.

@thinkyhead @p3p Well... Right now is a good time to express opinions and recommendations. It may not be too hard to get the HAL folders setup logically from the very start. But any subsequent, improved layout and organization for the HAL's will be welcomed also.

[p3p]

Would it be possible to just pull in the Arduino libraries so we don't have duplicated code complicating things

In the case of Wire all Arduino based platforms could still use it, but the calls would be through a standard API such as i2c_begin(channel, address), i2c_send_byte(channel, data), that other platforms would implement themselves or through another framework.

[tcm0116]

What can I do to help with this effort? I've got a bit of free time in the evenings this week, so I'm happy to help out if I can.

[Roxy-3D]

I think it is a little too early to do anything. We need the new organization to happen and be in place. But as soon as that happens... Several important items are on the list:

• Simple, step by step directions for getting the firmware onto a Re-ARM board. (Using Cygwin in a Windows environment would be preferable, but if we have to bring up a Linux machine, that would be tolerable.) -- Any extra configuration required. -- Steps to compile and build image outside of Arduino -- Steps to flash including notes on using the 2nd USB port -- Etc.
• Simple, step by step directions for getting the firmware onto other 32-Bit boards.
• It maybe good to have a thread showing how far the boot process is working for each 32-bit board type. And what sub-systems of Marlin still need attention for the board.
• It will also be good to have the 32-Bit developers look at the new layout and suggest changes (and submit Pull Requests) to organize things better for themselves.

I believe there is a lot of pent up demand for an official 32-Bit version of Marlin. If we can just get one board up and working with the new release, and clear instructions so anybody can duplicate the success... We should see a lot of activity. And my guess is a number of different 32-Bit boards will start to have people using them.

[p3p]

This information is very old, please use the official bugfix-2.0.x branch and using platformio build for LPC1768 if you have a Re-ARM board

Simple, step by step directions for getting the firmware onto a Re-ARM board.

1: Clone https://github.com/p3p/Marlin.git and checkout branch 32bit-bugfix-1.1.x-LPC1768 2: Install PlatformIO IDE 3: Open project in PlatformIO and build for Re-ARM (click bottom left of screen and scroll to bottom of options) 4: Copy firmware (/.pioenvs/Re-ARM/firmware.bin) to an sd card and put into Re-Arm

I've maintained compatibility with the Arduino pin layout so the same pins files should work (tested with RAMPS14).

This is a work in progress so once Marlin is flashed to the Re-ARM you lose access over usb to serial and the micro sd card, you will need another means of accessing the sdcard and an ftdi cable to access the 6 pin hardware serial port on the Re-ARM.

As of today I'm printing* with Re-ARM, steppers, heaters, ADC, SD card and graphical controller all work (character displays probably will not, they are more closely integrating with Arduino) using my RAMPS14, so basic functionality is at least out of the way.

[Roxy-3D]

@p3p THANK YOU SO MUCH! I'm going to start messing with getting some simple firmware compiled and loaded into a Re-ARM board using your steps... I'll at least be in a position to start messing with different things when the time comes!

[Roxy-3D]

@p3p Up above you say to 'build for Re-ARM'. I can't find that in the list. But I did find Platform NXPLPC NXP mbed LPC1768. Is that the correct selction for the Re-ARM board?

I'm also having trouble getting the project to open up in PlatformIO. But I did get something to happen when I dragged and dropped the platformio.ini file onto my Atom icon on the desk top. A little more info on what I do to open the project would be helpful too!

[Grogyan]

I too am having trouble. Though we might need to generate a platform specifically for the Re-ARM http://docs.platformio.org/en/latest/platforms/creating_board.html

[p3p]

When you open Atom it should open onto a Home screen, one of the Quick Access options is to "Open Project" if you browse to the folder containing platformio.ini and click open, in the left panel you should get the Marlin project file listing (.github, buildroot, &c.) from here you should be able to click the PIO build in the bottom corner and scroll down to Re-ARM

[p3p]

Though we might need to generate a platform specifically for the Re-ARM

Using the LPC1768 board with a modified linker script for compatibility with the smoothieware bootloader works well for now but we could do that in the future. The Re-ARM build is defined in the platformio.ini file so as long as you have correctly checked out the branch it should be there.

[Grogyan]

Thanks Chris, Posting a couple of screenies to help others

https://user-images.githubusercontent.com/6621978/27358346-49d44a66-566a-11e7-9e48-77e386830f93.png https://user-images.githubusercontent.com/6621978/27358349-517a2268-566a-11e7-88be-2c1e29771f31.png

[Roxy-3D]

Ooooops! I managed to do a Re-ARM Upload. But I had my Atmega2560 with a RAMPS board plugged in.... My LCD screen went crazy.

THANKS p3p!!!

[p3p]

Just don't expect too much when (if) you get it on the hardware I only got the heaters working this afternoon ^^ and if you change the config it will probably explode .. I also just noticed an issue with corruption in the serial data during a test so that's my task tonight (he says at 23:30)

[Roxy-3D]

Yeah... Don't worry about that! I'm just trying to get up the learning curve because my guess is when we get the new file layout, progress is going to be made fast. I don't want to be left behind.

So... I'm going to be playing with a lot of stuff. Mostly simple stuff. But I want to understand all the steps and how the development environment works. And then... Who knows, maybe I can help with some of the simpler stuff like getting the 20x4 LCD Displays working.

The point is, when 32-Bit progress can be made against the current code base, eventually.... everything will be working even though the code base kept evolving as that was happening. And if people can run the current code base on 32-Bit platforms... More and more people will jump on-board.

[paulusjacobus]

Hey @Roxy-3D is that Ray Cortes kickstarter board? https://www.kickstarter.com/projects/1245051645/re-arm-for-ramps-simple-32-bit-upgrade I did order it for $48 for my 3D printer and it's gathering dust at the moment. I would be really interested to see this getting of the ground. I'm doing a kickstarter for my Gerbil K40 laser controller at the end of the month so I cannot contribute much but I'm eager to learn how to port code to this environment. Where can I follow it in detail?

On 21 June 2017 at 08:47, Roxy-3D notifications@github.com wrote:

Yeah... Don't worry about that! I'm just trying to get up the learning curve because my guess is when we get the new file layout, progress is going to be made fast. I don't want to be left behind.

So... I'm going to be playing with a lot of stuff. Mostly simple stuff. But I want to understand all the steps and how the development environment works. And then... Who knows, maybe I can help with some of the simpler stuff like getting the 20x4 LCD Displays working.

The point is, when 32-Bit progress can be made against the current code base, eventually.... everything will be working even though the code base kept evolving as that was happening. And if people can run the current code base on 32-Bit platforms... More and more people will jump on-board.

— You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/7076#issuecomment-309913380, or mute the thread https://github.com/notifications/unsubscribe-auth/AIOTKVmipb4ymHxTHrBPpX65nKSnQTPDks5sGEwBgaJpZM4N82_j .

[Roxy-3D]

It is not Ray's board. I have that on my desk too. But I'm trying to learn how to generate code with the PlatformIO IDE.

@p3p I obviously don't understand something... I thought I built the firmware OK, and put it on the SD Memory card. But nothing happened on the Graphical LCD Panel when I started up the board. So I'm not sure what I'm fighting and decided to just try to make an LED blink. I added this code to Marlin_main.cpp

void pinMode(int pin, int mode);
void digitalWrite(int pin, int pin_status);
bool digitalRead(int pin);
void analogWrite(int pin, int pin_status);
uint16_t analogRead(int adc_pin);

void setup_LEDs() {
int p, r, t, s;

    for(p=1; p<54; p++) {
        pinMode(p, OUTPUT);
    for(r=0; r<10; r++) {
            digitalWrite(p, LOW);  // drive it down
        s = 0;
        for(t=0; t<5000; t++) {
            s=s+digitalRead(20)&0x01;
            }
            digitalWrite(p, HIGH);  // drive it up
        for(t=0; t<5000; t++) {
            s=s+digitalRead(20)&0x01;
            }
            digitalWrite(p, LOW);  // drive it down 
    }
        pinMode(p, INPUT);
    }
}

and then in the setup() function I called it:

void setup() {

  #ifdef DISABLE_JTAG
    // Disable JTAG on AT90USB chips to free up pins for IO
    MCUCR = 0x80;
    MCUCR = 0x80;
  #endif

  #if ENABLED(FILAMENT_RUNOUT_SENSOR)
    setup_filrunoutpin();
  #endif

  setup_LEDs();

I have LED's plugged into different places on the Re-ARM board. (Right now, what would be pins 1,2 and 3 on an ATMega-2560 board) and I do see some changes in them when I reset the board. But I don't get on and off blinks like I expect. Obviously, I'm missing something. Can you change the setup_LEDs() so it blinks an LED for me? With that I'll be able to make a lot more progress.

[p3p]

Without the serial connection it will be hard to know what went wrong, can you confirm the firmware was written correctly, the Re-ARM renames "firmware.bin" to "firmware.cur" after flashing. Assuming that's correct you should at least get serial output (and the logo if the config is compatible with your setup).

[Roxy-3D]

Without the serial connection it will be hard to know what went wrong, can you confirm the firmware was written correctly, the Re-ARM renames "firmware.bin" to "firmware.cur" after flashing.

Yes... It is renaming the file.

Assuming that's correct you should at least get serial output (and the logo if the config is compatible with your setup).

I do not have the board connected up to any endstops or stepper motors yet. And I maybe fighting the problem where some graphical displays have reversed cables. I don't know what I'm fighting. That is why I thought I would start small and try to blink an LED. But I can't even make that happen right now. So I have a pretty big learning curve in front of me.

It appears you re-mapped the ReARM connector locations to match the Atmega2560/RAMPS board locations... I'm getting a lot of warnings when trying to use that code. I found the documentation showing the Re-ARM Port and Pin numbers.... I can go after those LED's in the Re-ARM's address space now. And then migrate back to the RAMPS locations...

Don't worry about me... I'll figure it out.

[p3p]

The functions (digitalWrite, pinMode ect) that I wrote make the pin mapping transparent, you just use them as you would on Arduino Mega, not all pins have been mapped yet (or can be) pinmap_re_arm.h controls that.

With nothing plugged into the Re-ARM it should still boot up into Marlin and you can control it via the serial port, without more information about what is being output I can't really help, Displays and controllers I wasn't expecting just to work unless they are identical to reprap full graphic smart controller.

If you don't have a ftdi cable you can forward the serial through an Arduino but I recommend getting one they come in handy.

[p3p]

I just realised you didn't say if the LCD display was powering up or that you used the adaptor cable from http://www.panucatt.com/product_p/glcd-idc.htm to connect it, all that cable does is split pin 1 off so you can connect it to a 5v pin on the Re-ARM.

If you do want to run code on the Re-ARM without any of Marlin getting in the way, there is a main function in HAL.cpp that calls setup and loop just comment them out. From there you should at least be able to toggle Digital outputs for testing.

[Roxy-3D]

I do get the Graphics LCD Screen to light up. (RepRap Discount Full Graphic Smart Controller) I have the split cable and apparently did get the +5 volt wire to work. I just don't have anything being displayed on it (yet). I'll keep plugging away.

And I just brought the LCD Panel up on an ATMega2560 board... So I have the cable correct.... Next I'll move things over to the LPC1768

[thinkyhead]

I'll try to apply the new file layout incorporating the HAL this weekend and post a 2.0.x branch that we can patch up for release. This will just be a first attempt, and can be reworked as needed.

We might still have too many open issues needing fixing before we jump ahead, but at least this will provide a starting point. I haven't counted open issues lately, but I will do an audit and try to produce a list of lingering bugs and issues that we should fix ahead of the new layout.

[Roxy-3D]

We might still have too many open issues needing fixing before we jump ahead, but at least this will provide a starting point. I haven't counted open issues lately, but I will do an audit and try to produce a list of lingering bugs and issues that we should fix ahead of the new layout.

@thinkyhead From reading all the new issues and posts to them... There doesn't seem to be anything critical. We have a few questions about BL-Touch probes not working. We have a couple of bed leveling issues across the spectrum of different bed leveling schemes. But nothing dire.

My suggestion would be, we cut and run. Until the new folder and file layout is complete, people can just continue with today's bugfix-v1.1.x .

[Roxy-3D]

@thinkyhead @p3p I moved the LPC1768 changes for the Re-ARM board over to 32-Bit-RCBugFix-new just to make sure they don't get forgotten! We need p3p's LPC1768 stuff in the new file & folder layout.

It isn't passing the Travis tests... But it is here as a Pull Request: https://github.com/MarlinFirmware/Marlin/pull/7121 I wonder if we should merge it anyway just to make sure it is part of the mix?

[thinkyhead]

Now that the bugfix-2.0.x branch has been created, we can try to bring over the elements from oh-so-older 32-Bit-RCBugFix-new branch, including your new changes in #7121, if they're ready for inclusion and/or consistent with the HAL stuff from @teemuatlut and @p3p.

I'd like to get the HAL elements pretty well organized ahead of the rest of the code reorganization, since all other components will depend on it.

[p3p]

@thinkyhead The new branch was based on 32-Bit-RCBugFix-new so I'm relatively sure there is nothing missing that was in there (although I seem to remember there was some issue rebasing @teemuatlut's PIN DEBUG code), I was back-porting anything that was general HAL from the LPC1768 branch into the PR but I do have to finish the new SPI integration (I have to implement it for the other platforms), then I would like to continue moving the HAL features into the HAL::Feature naming convention (HAL::ADC , HAL::I2C, ect) with general headers.

[teemuatlut]

You can leave the pins debug for Teensies in whatever state. I'll go over it once everything has settled down.

[oysteinkrog]

@thinkyhead You said in the first post that the aim for 1.1.5 was to fix all obvious bugs.. well dual X carriage has been broken since 1.1.1. See #6956 #7050 #7291.

[teemuatlut]

I may be interested in finding a fix for this as I'm building a dual X machine myself, but I can only get to it next week so if it's not solved by then I'll take a crack at it. Further discussion should be made on #7291

[oysteinkrog]

@teemuatlut I've tracked down the problem and I have submitted a PR that fixes it. It's great to have more people with DUAL_X_CARRIAGE though as I'm pretty sure there are still bugs related to it.