Marlin 2.0 Refactor

[thinkyhead]

Where to find it

The bugfix-2.0.x-new-layout branch is a refactoring of the Marlin 2.0 codebase which includes the 32-bit HAL.

I'll be doing the meticulous work in my bugfix_refactor_work branch, and will make sure to keep the bugfix-2.0.x-new-layout branch in a working state for testing. Please report if it isn't compiling and I will aim to fix it quickly!

Development roadmap

The intent is to produce a more logically organized and granular codebase, encapsulate globals and their related g-code handlers into static singletons, by feature, and produce a codebase that will be easier to extend. As a refactor, the code size, logic, and performance is meant to remain unaltered. However, in practice, the inlining, linking, and calling behavior is bound to change. Please report any major changes in performance.

As this code develops, you may find things about it bothersome. This code will continue to develop and improve largely according to your feedback. Nothing in the branch is written in stone, and all ideas are welcome.

Initial status

As of this writing the branch has been through a couple of iterations, and it compiles successfully for both Arduino IDE and PlatformIO, giving a near-identical binary as the current "flat" codebase. The g-code handlers are split out into .h files to start to encapsulate them into units, by feature, where possible. This initial breakup into .h files was a good first step, as the main thing was to produce a new layout that could compile but without making any functional change to the firmware. This is proving a useful organization from which to go forward with the next step…

Static classes, namespaces

We don't have to sacrifice compiler optimizations such as inlining smaller handlers just because we move things into .cpp files, so long as all the g-code handler code is encapsulated into static singletons. The smaller inline-able methods can be defined in the .h files of the new singletons, while the bigger handler functions that only bloat the process_next_command function can be static.

The G-code handlers can be moved into singletons by an almost automatic process, taking each G-code handler now inside an .h file and doing a quick refactor…

• Rename the .h to .cpp file and compile to see where it fails, citing dependencies.
• Bring in the needed extern and #include lines to resolve the dependencies.
• In some cases shift the definition to the g-code handler files, or added headers.

By doing this in groups of G-codes that all relate to the same config option, they can then be grouped into a singleton class, any feature-related globals and functions currently defined in Marlin.cpp will be moved to the new singleton class. Any functions they share with other config features can be encapsulated in a shared friend class.

The static class instance has been chosen rather than pure namespaces because they provide some extra features and syntactic sugar. The instances are superfluous, but allow us to use dot-notation to access class data. (planner.something() does the same as Planner::something()).

Parallel Development

As long as most development and bug-fixing to bugfix-2.0.x focuses on the HAL, I can continue to refine the G-code handling code and restructure this branch without disrupting that work. As long as patches made to Marlin_main.cpp and other files are straightforward, they shouldn't be hard to bring into the refactored branch, as the intent is only to reorganize and not, largely, to modify the code.

Branch Cleanup

To make it easier to follow changes, I will re-build the bugfix-2.0.x-new-layout commits again except this time I will move all the files, unchanged (except renames), to their new locations, and only afterward apply all the textual changes to the files. That set of textual changes will be primarily to the #include lines, so it should make a nice picture of how dependencies are affected.

Timetable

• [x] 6 Sept: Rebuilt branch commits, identical to current time (5 Sept)
• [x] 7 Sept: Some G-code handlers refactored into feature singletons.
• [x] 9 Sept: Consolidate motion, kinematics, leveling, etc.
• [x] 12 Sept: Complete handler refactoring.
• [ ] Oct-Nov: Refactor LCD and other code as static singletons, as appropriate

@MarlinFirmware/32bit-maintainers

[thinkyhead]

Build 9-20

I've patched all the reported compiler errors, and M100 should now work in the 32-bit environments, displaying 8-digit hex addresses.

Thank you for your patience and forbearance through the refactoring process. The initial rearrangement is the hardest part, and basically a lot of grunt work, trial-and-error, and cursing the dreaded ❌ every time Travis CI choked.

Next Steps

If there are no objections, I could simply replace the bugfix-2.0.x branch with the refactored one, then if anyone has patches for the HAL or other parts of the code, you can just make them to the updated codebase. If some are hard to apply, let me know and I don't mind applying them manually, if necessary. Apart from necessary tweaks, most changes to the HAL are entirely spacing-related. Stripping excess whitespace before diffing should produce leaner output.

I'd like to do more testing with the Re-ARM and get my character display working (especially since I don't have a graphical display at the moment). We'll definitely want to have that working with the first release, if it's at all possible. I'll replace the RAMPS on my i3 with the Re-ARM this weekend and get into that, if I don't get too bogged down with bug-fixes.

1.1.x Issue Queue

There are some issues piling up in the queue that will need patches to the 1.1.x code. Some of these are important, so my plan is to take every patch to 1.1.x and also apply it to 2.0.x. As for new features, they can also be added to 2.0.x within the feature-based layout. At this time the internal APIs are mostly identical to 1.1.x, so it should be easy to bring things over during this transitional period.

Comments?

Hopefully this refactor provides a good starting foundation for the next generation of Marlin and customized forks, with an eye towards modularity. Interested contributors and GitHub members may comment on the new file layout, suggest improvements, and so on.

There will continue to be some rearrangement — for example, adding a cartesian.cpp module, splitting up the three different forms of auto-bed-leveling so they can be seen in their essence, and evaluating whether relocating G-code handlers into their relevant classes is sensible. The motion.cpp module is a pretty big stew, so that may be split up even further. And the lcd code needs some work to replace the code-generating includes (rightly frowned-upon as an unnecessary cheat) with proper .cpp files.

Onward….

[Roxy-3D]

If there are no objections, I could simply replace the bugfix-2.0.x branch with the refactored one

Yes. Agreed.

There are some issues piling up in the queue that will need patches to the 1.1.x code. Some of these are important, so my plan is to take every patch to 1.1.x and also apply it to 2.0.x

Yes. Agreed.

There will continue to be some rearrangement — for example,

Probably the best thing to do is let things stabilize for a while. Once development activity gets back to normal let's just contain the refinement to one well defined area at a time. Otherwise everything grinds to a halt. This re-organization was needed but it was very disruptive. Things need to stabilize.

My guess is if we replace the current bugfix-2.0.x branch with the re-organized one and start pointing people to it... It will take a few weeks to get all the hiccups out of it and back under control. That is OK! And then, further refinement of various sub-systems can continue.

[Bergerac56]

@thinkyhead . All my tests are done with bugfix 2.0.x New layout. I just gave a try to the last version:

1. I made a print with a cylinder in lower résolution. And your guess is right. With a resolution of 30, it prints normally. With a resolution of 100, it shakes. This seems to mean that there is a problem with very small moves (re-am.). Btw, I tested also the bugfix 2.0.x (non new layout) and the problem is the same.
2. UBL/ Building a mesh for PLA from the LCD screen works now
3. Time to time, strange moves. The X and Y motors vibrate and they seems to lose their correct position. It could be the printer but it never happened with the atmega. Is it due to the re-arm and its 3.3v? Or does it come from the "small moves" potential problem?
4. Still not compiling for re-arm with case_light. Another "not declared" stuff:

   Marlin\src\feature\caselight.cpp: In function 'void update_case_light()':
   Marlin\src\feature\caselight.cpp:38:44: error: 'USEABLE_HARDWARE_PWM' was not declared in this scope
   if (USEABLE_HARDWARE_PWM(CASE_LIGHT_PIN)) {
   ^
   Marlin\src\feature\caselight.cpp:36:11: warning: unused variable 'case_light_bright' [-Wunused-variable]
   uint8_t case_light_bright = (uint8_t)case_light_brightness;
   ^~~~~~~~~~~~~~~~~
   *** [.pioenvs\Re-ARM\src\src\feature\caselight.o] Error 1

[p3p]

@thinkyhead I think replacing bugfix-2.0.x is the best option, and getting people testing 2.0 on AVR is very important for a smooth transition to it being the default dev branch. The other platforms need testing too but AVR has to be a priority at this point. (says the man that doesn't have any printers that run AVR)

[Roxy-3D]

I think replacing bugfix-2.0.x is the best option, and getting people testing 2.0 on AVR is very important for a smooth transition to it being the default dev branch.

From another perspective... If the outstanding Pull Requests are duplicated and applied to the new bugfix-2.0.x that allows us to freeze bugfix-1.x.x It makes it much easier to say "bugfix-2.0.x is where you should be."

[fiveangle]

PRs #7699, #7700, #7706, #7701 currently open against bf20ng branch to fix some AVR/Due compile errors found in issues list so could probably be applied before R&R of the new layout branch to bug fix-2.0.x

[thinkyhead]

Probably the best thing to do is let things stabilize for a while. if we replace the current bugfix-2.0.x branch … and start pointing people to it... It will take a few weeks … That is OK!

I agree. The only last-minute tweaks that I would do at this point would pertain to the compiler errors reported above, and general cleanup. There's no point where it can all be "perfect" but we can keep refining as we go along. The first Marlin 2.0 release can be a little rough around the edges, and we'll get it into more ideal shape by the time we tag 2.0.5.

With that in mind, I'll apply the patches from @fiveangle and any others we need, and update bugfix-2.0.x forthwith. (The current bugfix-2.0.x will be backed up as bugfix-2.0.x-backup-21092017.)

[thinkyhead]

Still not compiling for re-arm with case_light.

I see that USEABLE_HARDWARE_PWM is only defined for AVR. @Bob-the-Kuhn could probably tell you off the top of his head what the new test should be. I'll see if I can figure it out and add a macro for the other platforms. I think the issue is that we aren't super familiar with the scope of PWM and Timer relationships on each of these new chips.

[Bob-the-Kuhn]

Here's the USEABLE_HARDWARE_PWM for the LPC1768. case_light.zip

case_light now compiles BUT I have not been able to test it. I have not been able to build an image that runs from the reorg branch.

[Bob-the-Kuhn]

It appears that I'm running into some kind of linker or symbol table problem.

I can see the start of several routines in FLASH right where the ELF files says it'll be but the branches to these routines end up somewhere else.

The VTOR register says the vector table starts at 0 but it's actually at 0x0000 4000.

I used PlatformIO to compile the bugfix-2.0.x-new-layout branch from early this evening. The only change I made was to set the board to BOARD_RAMPS_14_RE_ARM_EFB, set the machine name, set the author and set the temp0 sensor to 998.

---

When I single step from a reset ,the PC is picked up from address 4 which is 0x0000 AAAD so the execution starts at 0x0000 AAAC. The problem is that's not where the reset routine is located. It's actually at 0x0000 41AC. The vector table is actually at 0x0000 4000. When I look at VTOR it's contents are 0x0000 0000.

The object dump of the ELF file and the disassembly in the debugger agree on the 0x0000 4xxx addresses.

Apparently that's just the first problem. When I set the PC to 0x0000 41AC I can follow the execution through the reset routine but when it branches to the SystemInit routine it doesn't go to the right place. Using the objectdump & the debugger I can see the SystemInit code in FLASH right where the ELF file says it should be.

[alex-gh]

The VTOR register says the vector table starts at 0 but it's actually at 0x0000 4000.

Makes sense, the bootloader lives in the first 16k.

Does the marlin code touch VTOR somewhere?

Otherwise this should be the last location that touches VTOR.

[Bergerac56]

@Bob-the-Kuhn . I tried the last version of Bugfix 2.0.x NL adding the corrections for case_light for re-arm. It compiles now if the option MENU_ITEM_CASE_LIGHT is disabled. EDIT: I tried on my "re-arm" printer and the function works (M355 S0-S1). If MENU_ITEM_CASE_LIGHT is activated, compilation fails:

Marlin\src\lcd\ultralcd.cpp: In function 'void case_light_menu()':
Marlin\src\lcd\ultralcd.cpp:258:41: error: cannot convert 'int*' to 'int16_t* {aka short int*}' for argument '2' to 'void menu_action_settin
g_edit_callback_int3(const char*, int16_t*, int16_t, int16_t, screenFunc_t, bool)'

And:

menu_action_ ## TYPE(__VA_ARGS__); \
^
Marlin\src\lcd\ultralcd.cpp:269:7: note: in expansion of macro '_MENU_ITEM_PART_2'
_MENU_ITEM_PART_2(TYPE, LABEL, ## __VA_ARGS__); \
^~~~~~~~~~~~~~~~~
Marlin\src\lcd\ultralcd.cpp:310:53: note: in expansion of macro 'MENU_ITEM'
#define MENU_ITEM_EDIT_CALLBACK(type, label, ...) MENU_ITEM(setting_edit_callback_ ## type, label, PSTR(label), ## __VA_ARGS__)
^~~~~~~~~
Marlin\src\lcd\ultralcd.cpp:774:7: note: in expansion of macro 'MENU_ITEM_EDIT_CALLBACK'
MENU_ITEM_EDIT_CALLBACK(int3, MSG_CASE_LIGHT_BRIGHTNESS, &case_light_brightness, 0, 255, update_case_light, true);
^~~~~~~~~~~~~~~~~~~~~~~
Marlin\src\lcd\ultralcd.cpp:262:113: error: cannot convert 'int*' to 'int16_t* {aka short int*}' for argument '5' to 'void lcd_implementatio
n_drawmenu_setting_edit_callback_int3(bool, uint8_t, const char*, const char*, int16_t*, ...)'

[Bergerac56]

@thinkyhead Could you also add the solution for filtering temp developped here ? Pid stability ReArn #7585

[alex-gh]

@Bob-the-Kuhn One more idea with regards to the strange problem you are having. Are you singlestepping right after reset? If so the CPU might be in the boot ROM region.

It is automatically mapped to 0 after each reset. Check the MEMMAP register to verify.

[Tannoo]

So, I see that bugfix-2.0.x is now just about leaving the Arduino IDE behind.

The only files visible from the IDE are Marlin.ino, Configuration.h, and Configuration_adv.h.

Unless I'm missing some new IDE configuration.

[Tannoo]

I am using IDE 1.8.4.

[Tannoo]

Will PlatformIO compile and send to the Mega?

[p3p]

@Tannoo The Arduino toolchain supports folders but the IDE doesn't appear to display them, thinkyhead moved the configuration files back to the folder containing Marlin.ino in order to make it easy for end users to modify configs and compile, this is about the only use of the Arduino IDE anyway you can't use it for development.. (ok that's only an opinion).

[Tannoo]

Ok. I will have to load the project in PlaformIO to find the compile errors I'm getting with the IDE.

I will dive into that in the am.

[Roxy-3D]

My vote is Arduino can pull in v2.0.0 and compile for the AVR's. And Platform-IO can compile for some of the 32-bit boards and also do AVR's.

[Tannoo]

The AVR IDE compiles just fine if everything is left as default.

[Tannoo]

Arduino IDE

[Bergerac56]

@Tannoo I would give a try to PIO even if i found it not so easy to start with (not very stable).

But, then, you find back all your files and can upload to AVR without problem. And, as Roxy says, you can compile for mega and re-arm

[Tannoo]

Oh yeah. PIO compiles my Re-ARM just fine. I have not used PIO for AVR though.

[Tannoo]

Everything was fine until the new layout got into bugfix-2.0.x.

[Bergerac56]

I just checked the last version of bugfix-2.0.x. . I suppose that, since now, it will be the "track to follow". Am I right? This version compiles fine with PIO for atmega. (As it was the case for bugfix 2.0.x new layout). But still problems to compile with case_light enabled for re-arm.

[Tannoo]

So, I did get the error sorted and PIO compiled and uploaded to the Mega.

[p3p]

I just checked the last version of bugfix-2.0.x. . I suppose that, since now, it will be the "track to follow". Am I right?

@Bergerac56 bugfix-2.0.x is the the dev branch for 2.0, there have just been varying levels of bleeding edge for the last few weeks,(they were pretty much just thinkyheads working branches), this is now converging again thankfully.

@Roxy-3D I think the aim is to keep Marlin building with Arduino IDE for any platform that supports it, but the Arduino IDE was never designed to develop anything more than simple projects linking together a few libs so we are not worrying about the files/folders not showing up (other than the configs). If PlatformIO (Atom IDE) was a bit more .. seamless .. I would say just switch to that as default for end users but the variability in how easy it to setup (from simple to impossible apparently) that's not an option.

We do have #7707 to worry about though, The Arduino toolchain is limited by the maximum command length of the OS .. with the now longer paths because of the reorganise it has become a problem it seems.

[Bob-the-Kuhn]

@Bergerac56 - this compiles for me when MENU_ITEM_CASE_LIGHT is enabled. It also fixes the S0, S1 options so they actually do something on Re-ARM. case_light_2.zip

I'm not able to test the MENU_ITEM_CASE_LIGHT option. My system won't run when I have VICKY2 enabled.

[Bergerac56]

@Bob-the-Kuhn - I tested with the content of your case_light_2 spead on the right places (I think ;) ) and... it does not compile. Message:

Compiling .pioenvs\Re-ARM\src\src\feature\caselight.o
Marlin\src\feature\caselight.cpp: In function 'void update_case_light()':
Marlin\src\feature\caselight.cpp:51:44: error: 'USEABLE_HARDWARE_PWM' was not declared in this scope
if (USEABLE_HARDWARE_PWM(CASE_LIGHT_PIN)) {
^
Marlin\src\feature\caselight.cpp:57:44: error: 'USEABLE_HARDWARE_PWM' was not declared in this scope
if (USEABLE_HARDWARE_PWM(CASE_LIGHT_PIN))
^
*** [.pioenvs\Re-ARM\src\src\feature\caselight.o] Error 1
 [ERROR] Took 19.21 seconds

[fiveangle]

7695 really needs to be applied because we can't compile many AVR targets using PIO due to PIO trying to compile the LPC17xx HAL. @tcm0116's commit failed Travis because of a compile error in UBL validation due to the break up:

The command "build_marlin_pio ${TRAVIS_BUILD_DIR} ${TEST_PLATFORM}" exited with 0.
0.01s$ restore_configs
The command "restore_configs" exited with 0.
0.02s$ opt_enable NUM_SERVOS Z_ENDSTOP_SERVO_NR Z_SERVO_ANGLES DEACTIVATE_SERVOS_AFTER_MOVE
The command "opt_enable NUM_SERVOS Z_ENDSTOP_SERVO_NR Z_SERVO_ANGLES DEACTIVATE_SERVOS_AFTER_MOVE" exited with 0.
0.01s$ opt_set NUM_SERVOS 1
The command "opt_set NUM_SERVOS 1" exited with 0.
0.02s$ opt_enable AUTO_BED_LEVELING_3POINT DEBUG_LEVELING_FEATURE EEPROM_SETTINGS EEPROM_CHITCHAT
The command "opt_enable AUTO_BED_LEVELING_3POINT DEBUG_LEVELING_FEATURE EEPROM_SETTINGS EEPROM_CHITCHAT" exited with 0.
0.02s$ opt_enable_adv EXTENDED_CAPABILITIES_REPORT AUTO_REPORT_TEMPERATURES AUTOTEMP G38_PROBE_TARGET
The command "opt_enable_adv EXTENDED_CAPABILITIES_REPORT AUTO_REPORT_TEMPERATURES AUTOTEMP G38_PROBE_TARGET" exited with 0.
5.57s$ build_marlin_pio ${TRAVIS_BUILD_DIR} ${TEST_PLATFORM}
Marlin/Marlin_main.cpp: In function 'void gcode_G29()':
Marlin/Marlin_main.cpp:4505:21: warning: unused variable 'abl2' [-Wunused-variable]
int constexpr abl2 = 3;
^
/tmp/cccXj0v9.ltrans0.ltrans.o: In function `process_next_command()':
cccXj0v9.ltrans0.o:(.text+0x22d6): undefined reference to `Servo::move(int)'
cccXj0v9.ltrans0.o:(.text+0x2304): undefined reference to `Servo::read()'
/tmp/cccXj0v9.ltrans1.ltrans.o: In function `set_probe_deployed(bool)':
cccXj0v9.ltrans1.o:(.text+0x1322): undefined reference to `Servo::move(int)'
/tmp/cccXj0v9.ltrans3.ltrans.o: In function `handle_interrupts(timer16_Sequence_t, unsigned int volatile*, unsigned int volatile*)':
cccXj0v9.ltrans3.o:(.text+0x44): undefined reference to `ServoCount'
cccXj0v9.ltrans3.o:(.text+0x68): undefined reference to `servo_info'
cccXj0v9.ltrans3.o:(.text+0x6a): undefined reference to `servo_info'
cccXj0v9.ltrans3.o:(.text+0x92): undefined reference to `ServoCount'
cccXj0v9.ltrans3.o:(.text+0xba): undefined reference to `servo_info'
cccXj0v9.ltrans3.o:(.text+0xbc): undefined reference to `servo_info'
cccXj0v9.ltrans3.o:(.text+0x112): undefined reference to `servo_info'
cccXj0v9.ltrans3.o:(.text+0x114): undefined reference to `servo_info'
cccXj0v9.ltrans3.o:(.text+0x13e): undefined reference to `servo_info'
/tmp/cccXj0v9.ltrans3.ltrans.o:cccXj0v9.ltrans3.o:(.text+0x140): more undefined references to `servo_info' follow
/tmp/cccXj0v9.ltrans4.ltrans.o: In function `main':
cccXj0v9.ltrans4.o:(.text.startup+0x510): undefined reference to `Servo::attach(int)'
cccXj0v9.ltrans4.o:(.text.startup+0x518): undefined reference to `Servo::detach()'
cccXj0v9.ltrans4.o:(.text.startup+0x524): undefined reference to `Servo::move(int)'
/tmp/cccXj0v9.ltrans9.ltrans.o: In function `global constructors keyed to 65535_0_G26_Mesh_Validation_Tool.o.3750':
cccXj0v9.ltrans9.o:(.text.startup+0xac): undefined reference to `Servo::Servo()'
collect2: error: ld returned 1 exit status
*** [.pioenvs/megaatmega2560/firmware.elf] Error 1

I tried compiling with all those flags, and it worked with just a few warnings:

Compiling .pioenvs/megaatmega2560/lib/TMC2130Stepper/source/TMC2130Stepper_DRV_STATUS.o
.piolibdeps/TMC2130Stepper/src/source/TMC2130Stepper.cpp: In member function 'uint16_t TMC2130Stepper::microsteps()':
.piolibdeps/TMC2130Stepper/src/source/TMC2130Stepper.cpp:290:1: warning: control reaches end of non-void function [-Wreturn-type]
}
^
.piolibdeps/TMC2130Stepper/src/source/TMC2130Stepper.cpp: In member function 'uint8_t TMC2130Stepper::blank_time()':
.piolibdeps/TMC2130Stepper/src/source/TMC2130Stepper.cpp:308:1: warning: control reaches end of non-void function [-Wreturn-type]
}
^
.piolibdeps/TMC2130Stepper/src/source/TMC2130Stepper.cpp: In member function 'uint8_t TMC2130Stepper::sg_current_decrease()':
.piolibdeps/TMC2130Stepper/src/source/TMC2130Stepper.cpp:331:1: warning: control reaches end of non-void function [-Wreturn-type]
}
^
Archiving .pioenvs/megaatmega2560/lib/libServo.a
Compiling .pioenvs/megaatmega2560/lib/TMC2130Stepper/source/TMC2130Stepper_GCONF.o
Indexing .pioenvs/megaatmega2560/lib/libServo.a
Compiling .pioenvs/megaatmega2560/lib/TMC2130Stepper/source/TMC2130Stepper_IHOLD_IRUN.o
Compiling .pioenvs/megaatmega2560/lib/TMC2130Stepper/source/TMC2130Stepper_PWMCONF.o
Compiling .pioenvs/megaatmega2560/lib/LiquidCrystal_I2C_ID576/LiquidCrystal_I2C.o
Archiving .pioenvs/megaatmega2560/lib/libTMC2130Stepper.a
Indexing .pioenvs/megaatmega2560/lib/libTMC2130Stepper.a
Archiving .pioenvs/megaatmega2560/lib/libLiquidCrystal_I2C_ID576.a
Indexing .pioenvs/megaatmega2560/lib/libLiquidCrystal_I2C_ID576.a
Archiving .pioenvs/megaatmega2560/lib/libU8glib_ID7.a
Indexing .pioenvs/megaatmega2560/lib/libU8glib_ID7.a
Linking .pioenvs/megaatmega2560/firmware.elf
Building .pioenvs/megaatmega2560/firmware.hex
Calculating size .pioenvs/megaatmega2560/firmware.elf
AVR Memory Usage
----------------
Device: atmega2560
Program:   71382 bytes (27.2% Full)
(.text + .data + .bootloader)
Data:       2920 bytes (35.6% Full)
(.data + .bss + .noinit)
========================= [SUCCESS] Took 12.91 seconds =========================

@tcm0116 - it may be good to resubmit to see if travis is happy again (could be one of the many fixes applied to bf20 since you last submitted)

@thinkyhead - is it possible to move forward with #7695 and we can address the travis issues afterward if they still exist ?

Compiling for Printrboard_RevF with graphics panel for example fails in AIDE on Windows, works in AIDE on Mac, but not on PIO for either due to failures in the LPC17xx HAL (which isn't actually needed for the target):

Compiling .pioenvs/printrboard_revf/src/frameworks/CMSIS/LPC1768/driver/lpc17xx_dac.o
*** [.pioenvs/printrboard_revf/src/frameworks/CMSIS/LPC1768/driver/lpc17xx_can.o] Error 1
Marlin/frameworks/CMSIS/LPC1768/driver/lpc17xx_clkpwr.c:39:28: fatal error: lpc17xx_clkpwr.h: No such file or directory
#include "lpc17xx_clkpwr.h"
^
compilation terminated.
*** [.pioenvs/printrboard_revf/src/frameworks/CMSIS/LPC1768/driver/lpc17xx_clkpwr.o] Error 1
Marlin/frameworks/CMSIS/LPC1768/driver/lpc17xx_dac.c:38:25: fatal error: lpc17xx_dac.h: No such file or directory
#include "lpc17xx_dac.h"
^
compilation terminated.
*** [.pioenvs/printrboard_revf/src/frameworks/CMSIS/LPC1768/driver/lpc17xx_dac.o] Error 1
*** [.pioenvs/printrboard_revf/src/Marlin.ino.o] Error 1
========================== [ERROR] Took 2.63 seconds ==========================
================================== [SUMMARY] ==================================
Environment megaatmega2560      [SKIP]
Environment megaatmega1280      [SKIP]
Environment printrboard         [SKIP]
Environment printrboard_revf    [ERROR]
Environment brainwavepro        [SKIP]
Environment rambo               [SKIP]
Environment anet10              [SKIP]
Environment sanguino_atmega644p [SKIP]
Environment DUE                 [SKIP]
Environment teensy35            [SKIP]
Environment Re-ARM              [SKIP]
========================== [ERROR] Took 2.63 seconds ==========================

[fiveangle]

Reason I'm mentioning is that nobody can compile on Windows for targets with U8glib because of AIDE limitations (tries to pass gcc.exe a commandline that is >32k). There's a hacky work-around but an alternative is to just use Sublime Text 3/DevIoT/PIO (now that gepd has fixed it).

I was planning on a quick "Getting Started on Marlin 32-bit" video but since this Windows fiasco (due to increased path lengths with the new layout) it could easily be a "Compiling Marlin with PIO" video that covers everyone. Useful ?

[tcm0116]

is it possible to move forward with #7695 and we can address the travis issues afterward if they still exist ?

I'll try and get that fixed today

[fiveangle]

One thing that may keep at least 128k board users on Arduino IDE is that it is compiling smaller than PIO for both PROGMEM and SRAM, even for the simplest configurations o_O

AIDE 1.8.4:

Sketch uses 70594 bytes (27%) of program storage space. Maximum is 253952 bytes.
Global variables use 2914 bytes (35%) of dynamic memory, leaving 5278 bytes for local variables.
Maximum is 8192 bytes.

PIO core 3.4.1

Building .pioenvs/megaatmega2560/firmware.hex
AVR Memory Usage
----------------
Device: atmega2560
Program:   71382 bytes (27.2% Full)
(.text + .data + .bootloader)
Data:       2920 bytes (35.6% Full)
(.data + .bss + .noinit)

When my Printrbot_RevF was compiling on PIO, it was around 3.5k smaller on AIDE. No idea why that would be the case.

[Bob-the-Kuhn]

@Bergerac56 - those errors were fixed by the first set of files. Did you use them this time?

[Bergerac56]

@Bob-the-Kuhn - Ooops right. Sorry. I restarted from a clean version of bugfix and forgot the first file. Done. It compiles fine.

EDIT: It works fine. The graphic LCD functions are OK (ON:OFF and Brightness). Nice job ;). Thanks

[thinkyhead]

A workaround…?

- DECLARE_MENU_EDIT_TYPE(int16_t, int3);
+ DECLARE_MENU_EDIT_TYPE(int, int3);

[thinkyhead]

I'll take a stab at fixing #7707 by combining more G-codes together into single units.

[ejtagle]

Sorry about the question. I'd like to contribute an EEPROM over FLASH emulation (NOT based on the ones already floating on the net, that use an Erase/Write cycle of a fixed FLASH page for each byte that is being stored. Rather than that, my implementation groups and combines several writes into a page write, saving tons of writes to the FLASH (right now it uses just one FLASH E/W cycle for each M500 command, and distributes writes between a pool of FLASH pages, This means that, for example, using 16 FLASH pages, we end with 16x10000 = 160000 configuration stores maximum, more than enough for any reasonable use of that command (is even more than most EEPROMS offer!). And using 16 pages only consumes 16*256 =4096 bytes in the FLASH, My original implementation is written and tested on the SAM3 Due board, and it works. I have tested it very carefully. But i think this kind of emulation could also benefit other targets - It could easily be generalized for any other targets that do not have EEPROM on board, but have FLASH memory that can be self programmed That is why i ask... I could create a branch and do a pull request, but, instead, i'd like some opinions if the code could be generalized, if a better abstraction could lead to sharing between devices of the emulator...

EepromEmulation_Due.zip

By the way, i now realize the first block comment does not apply as an explanation on how this works (the comment was an explanation for a previous algorithm that i did that also worked, but not on Arduino Due due to some limitations the SAM3X flash controller has on Partial writes. (essentially, you can't reprogram a byte that has been programmed previously without doing a full page erase, otherwise, page bit corruptions happen)

The new algorithm is a way simpler. It just stores "blocks" of changes. A block is composed by the starting address of the EEPROM (2 bytes, LSB first), the count of changed values (1 byte), and the new values for that defined address range, Blocks are accumulated on a page sized RAM buffer, and blocks are created, merged and expanded as new bytes arrive (eeprom_write). As soon as the RAM buffer becomes full, the buffer is written to a new FLASH page on the current group of FLASH pages. We have at least 2 groups of FLASH pages (all groups are the same size). Once a group of pages becomes full, then the emulator "compresses" all the Blocks of that group into a new block that is stored on the pages of the next group. Then the actual group is erased and the next group becomes the actual group So, essentially, is more or less an storage of differences to the previous values. And we assume the emulated EEPROM default byte value is 0xFF

[fiveangle]

@thinkyhead - I'd hold off on any permanent work to resolve #7707 because it appears they have POC of a workaround in arduino-builder already that I tested and works:

https://github.com/arduino/Arduino/issues/6751#issuecomment-331879017

[alex-gh]

@ejtagle

I have no familiarity with the SAM3 controllers so I can't comment on your implementation, but I have been rolling the idea of EEPROM emulation in FLASH for LPC17XX/Re-ARM for a while in my head.

The minimum erase size for LPC17XX is one sector (4kB/32kB) and the minimum write size is 256 bytes.

My idea for emulating EEPROM was simpler:

• Erase the sector after getting M500
• Then for each call to "HAL::PersistentStore::write_data":
  • Read 256 bytes of flash. (not very efficient, but saves us from statically allocating 256 bytes)
  • Insert the data at requested offset.
  • Write 256 bytes of flash.

I have never actually tested or implemented this but in theory it should allow for using only one E/W cycle for each M500 command.

[fiveangle]

@Bob-the-Kuhn - can you tell me if I'm right that this redefine is correct ?:

In file included from Marlin/src/inc/MarlinConfig.h:37:0,
from /Users/speedster/dev/github/Marlin/Marlin/Marlin.ino:31:
Marlin/src/inc/Conditionals_post.h:1009:0: warning: "NOT_A_PIN" redefined
#define NOT_A_PIN 0 // For PINS_DEBUGGING
^
In file included from /Users/speedster/.platformio/packages/framework-arduinoteensy/cores/teensy/Arduino.h:2:0,
from /Users/speedster/.platformio/packages/framework-arduinoteensy/cores/teensy/elapsedMillis.h:29,
from /Users/speedster/.platformio/packages/framework-arduinoteensy/cores/teensy/WProgram.h:26,
from /Users/speedster/.platformio/packages/framework-arduinoteensy/cores/teensy/Arduino.h:1,
from /var/folders/q1/g9l9mqmn319fh27k43yqpy440000gr/T/tmpuqVitL:1:
/Users/speedster/.platformio/packages/framework-arduinoteensy/cores/teensy/pins_arduino.h:43:0: note: this is the location of the previous definition
#define NOT_A_PIN 127

From comments in teensy/pins_arduino.h it's clear that even Teensyduino guys didn't think that having NOT_A_PIN as 127 was normal:

// This allows CapSense to work.  Do any libraries
// depend on these to be zero?
#define NOT_A_PORT 127
#define NOT_A_PIN 127
#define NOT_AN_INTERRUPT -1

It sounds to me that 0 is correct and I should tweak Conditionals_post.h to #undef NOT_A_PIN immediately before setting defining as 0 to prevent the string of compile warnings ?

#ifdef TEENSYDUINO
    #undef max
    #define max(a,b) ((a)>(b)?(a):(b))
    #undef min
    #define min(a,b) ((a)<(b)?(a):(b))

    #define NOT_A_PIN 0 // For PINS_DEBUGGING
  #endif

I want to fix it only because it takes 10x longer for Sublime Text 3 to cat these errors to the screen than it does to actually do the compile 😝 )

[Roxy-3D]

I do everything on Windoze... But even I know you just do a >>/dev/null to get rid of error messages.

[Bob-the-Kuhn]

If you use Arduino they automatically define NOT_A_PIN as zero.

It looks like NOT_A_PIN is only used to check if a port index is valid.

As best I can tell all the Arduino port tables always have NOT_A_PIN as the first entry followed by portA, then portb, ... That way porta is index 1, portb is index 2, ... and index zero is always illegitimate.

If that's the case then any number over 13 would also do for NOT_A_PIN.

I can see why redefining it to 127 would cause a lot of error messages. It's used in pinMode, digitalWrite and digitalRead.

From the comment it appears that the CapSense library needed the 127 value at one time. I downloaded the current CapSense libraries pointed at by Arduino and they do not use NOT_A_PIN. I couldn't find the older ones.

My opinion is we only need to worry about an old CapSense library being used in a printer controller. That's pretty far fetched. I think changing back to zero is OK.

[Bergerac56]

@thinkyhead - I would like to come back on the problem when printing a cylinder with a good resolution. As explained, it makes the motors shaking. (problem with very short moves on RE-ARM). It still happens with the last release. Do you have an idea how to solve it? Thanks

[p3p]

@Bergerac56 Can you supply the problematic gcode to test with, I have a high resolution circle in my motion test gcode and have never had an issue before.

[tcm0116]

@Bergerac56 are you printing from an SD Card or from a host. If from a host, which one?​

[Bergerac56]

@tcm0116 and @p3p here it is (I tried from the SD card and from a host-repetier) EDIT: I tried on 2 different hardware setup: one full functionnal printer and one test setup (only the re-arm board was the same) JOP_TEST.zip. Configuration.zip

[github-actions[bot]]

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.