Marlin: [BUG] [Bugfix 2.0.x] Can't compile for DUE with u8glib

[rafaljot]

### Compile Error

1. When I compile with:

#define MOTHERBOARD BOARD_RAMPS_FD_V1
...
#define DOGLCD // Full graphics display

I get a warning:
sketch/src/gcode/control/M111.cpp: In static member function 'static void GcodeSuite::M111()':
/Users/xxxxxx/Library/Arduino15/packages/arduino/hardware/sam/1.6.11/cores/arduino/avr/pgmspace.h:103:61: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
#define pgm_read_word(addr) ((const unsigned short *)(addr))
^
sketch/src/gcode/control/M111.cpp:55:31: note: in expansion of macro 'pgm_read_word'
serialprintPGM((char)pgm_read_word(&debug_strings[i]));

=====================
2. When add:

define REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER

I get an error:
sketch/src/lcd/ultralcd.cpp: In function 'void lcd_status_printf_P(uint8_t, const char*, ...)':
sketch/src/lcd/ultralcd.cpp:4615:61: error: 'vsnprintf_P' was not declared in this scope
vsnprintf_P(lcd_status_message, 3 * (LCD_WIDTH), fmt, args);

=====================
3. When I add to HAL_Due.h, line 77:

ifndef vsnprintf_P

#define vsnprintf_P vsnprintf

endif

I get no compilation error , LCD doesn't work, clear, a lot of warnings like:
/Users/xxxxxx/Documents/Arduino/libraries/U8glib/src/clib/u8g_com_arduino_t6963.c:128:26: warning: assignment from incompatible pointer type [enabled by default]
u8g_input_data_port[7] = portInputRegister(digitalPinToPort(u8g->pin_list[U8G_PI_D7]));.

=====================
4. When I try the same with "MK4duo Firmware" LCD works.

[fiveangle]

There's no BOARD_RAMPS_FD_V1 board define. You must be using BOARD_RAMPS_FD ?

Did your controller compile/work with bugfix1.1.x ?

[rafaljot]

bugfix1.1.x with 32bit ? I have never tried Due with 1.1.x
It works with MK4Due and with Repetier.

line 108 in boards.h is:

define BOARD_RAMPS_FD_V1 1503 // RAMPS-FD v1

define BOARD_RAMPS_FD_V2 1504 // RAMPS-FD v2

define BOARD_RAMPS_SMART_EFB 1523 // RAMPS-SMART (Power outputs: Hotend, Fan, Bed)

[fiveangle]

bugfix1.1.x with 32bit ?

Ah, right. Sorry !

line 108 in boards.h is:

define BOARD_RAMPS_FD_V1 1503 // RAMPS-FD v1

So you are right. And pins.h has:

https://github.com/MarlinFirmware/Marlin/blob/bugfix-2.0.x-new-layout/Marlin/src/pins/pins.h#L301-L302

#elif MB(RAMPS_FD_V1) || MB(RAMPS_FD_V2)
  #include "pins_RAMPS_FD_v1.h"

But the fact remains, there is no such header file that contains the board defines:

https://github.com/MarlinFirmware/Marlin/blob/bugfix-2.0.x-new-layout/Marlin/src/pins/pins_RAMPS_FD.h
https://github.com/MarlinFirmware/Marlin/blob/bugfix-2.0.x-new-layout/Marlin/src/pins/pins_RAMPS_FD_V2.h

If you change the pins.h section above to this:

#elif MB(RAMPS_FD_V1)
  #include "pins_RAMPS_FD.h"
#elif MB(RAMPS_FD_V2)
  #include "pins_RAMPS_FD_V2.h"

Do you get further along ?

-=dave

[rafaljot]

ok. I'll check this but I'm pretty sure precompiler include pins_RAMPS_FD.h because initially I made some mistakes inside and got errors. :D I'll check it again.

[rafaljot]

I get it. It is IF-ELSE for RAMPS-FD in line 265 and repeated in line you provided 301, so 301-302 is dead code.
I made this pull request to correct this https://github.com/MarlinFirmware/Marlin/pull/7701
Nevertheless it won't correct my issue with u8glib described above. It is easy to recreate it. Just make this change in fresh config and try to build.

[fiveangle]

7706 should resolve vsprintf define error but it seems those warnings are valid. I've asked Scott to review.

[fiveangle]

7706 includes some additional tweaks so would be good for you to refresh your local copy to current and see if anything has improved

[rafaljot]

Unfortunately no. It doesn't initiate LCD, looks like communication with display i completely off.

[rafaljot]

I wonder is it only RAMPS-FD and Graphic LCD issue ?
Is there anyone who has managed to run ArduinoDUE + REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER ?

[montycb]

I'm using DUE and RADDS, with a RRD full graphics smart controller and have the same problem with the display, so it is not only the RAMPS-FD

[RalphSch]

I'm also trying to get RADDS running with Reprap discount and Anet 12864 displays without success :\ Today I checked the signals (RS, EN and D4) and they are present at the lcd connector. The displays are showing some weird chars and it looks like something is looping inside the display.

[RalphSch]

Maybe the signal is just too fast, the Anet 1.0 controller (Atmega1284p @16MHz) uses 1MHz clock signal rate, Due uses 5MHz (I'm glad to have a cheap bitscope micro).

[RalphSch]

Got it working :) Just add this to your pins or configuration file:

define ST7920_DELAY_1 DELAY_20_NOP

define ST7920_DELAY_2 DELAY_20_NOP

define ST7920_DELAY_3 DELAY_20_NOP

Lower delays didn't work (I used a shielded cable for the three SPI wires).

[Roxy-3D]

Unfortunately no. It doesn't initiate LCD, looks like communication with display i completely off.

Pretty much... I prefer to operate in the mode where any new release is 100% tested and only a few little obscure bugs show up. But this time things are different. v2.0.0 is trying to make the code base work with both 8-bit platforms and a variety of 32-bit platforms.

If we have good information about the failure... we can probably resolve the issue quickly. But this is a hugely complex task and there are going to be issues that show up. In 2 or 3 weeks (with lots of effort) we should have everything compiling correctly.

[montycb]

I tested the settings from @RalphSch and now the display is working for me, though i also had to shield the wires.

[rafaljot]

@Roxy-3D . I am impressed by your work. I reported issue to help not to disturb ;)

I tested DELAY_20_NOP but it didn't work to me. I also tried to find key difference between Marlin 2.0, Repeatier and Mk4due in HAL... they use custom _delay_ms and delayMicroseconds functions but I also read that now standard Arduino _dalay_ms function doesn't block interrupts. So probably it is old workaround.

[RalphSch]

Uhh, a lot of bugs, lots of work with Marlin on Due ..... I will help testing and debugging :)

• LCD is completely dead if PRINTCOUNTER is activated

Other bugs I've seen so far:

• M100_FREE_MEMORY_WATCHER broken:

sketch\src\gcode\calibrate\M100.cpp.o: In function check_for_free_memory_corruption(char const*)': sketch\src\gcode\calibrate/M100.cpp:211: undefined reference to__brkval'
sketch\src\gcode\calibrate/M100.cpp:211: undefined reference to __bss_end' sketch\src\gcode\calibrate\M100.cpp.o: In functionGcodeSuite::M100()':
sketch\src\gcode\calibrate/M100.cpp:329: undefined reference to __brkval' sketch\src\gcode\calibrate/M100.cpp:329: undefined reference to__bss_end'
collect2.exe: error: ld returned 1 exit status

• USE_CONTROLLER_FAN broken:

  sketch\src\feature\controllerfan.cpp: In function 'void controllerfan_update()':
  sketch\src\feature\controllerfan.cpp:33:9: error: 'X_ENABLE_READ' was not declared in this scope
  if (X_ENABLE_READ == X_ENABLE_ON || Y_ENABLE_READ == Y_ENABLE_ON || Z_ENABLE_READ == Z_ENABLE_ON || thermalManager.soft_pwm_amount_bed > 0
  ^
  sketch\src\feature\controllerfan.cpp:33:41: error: 'Y_ENABLE_READ' was not declared in this scope
  if (X_ENABLE_READ == X_ENABLE_ON || Y_ENABLE_READ == Y_ENABLE_ON || Z_ENABLE_READ == Z_ENABLE_ON || thermalManager.soft_pwm_amount_bed > 0
  ^
  sketch\src\feature\controllerfan.cpp:33:73: error: 'Z_ENABLE_READ' was not declared in this scope
  if (X_ENABLE_READ == X_ENABLE_ON || Y_ENABLE_READ == Y_ENABLE_ON || Z_ENABLE_READ == Z_ENABLE_ON || thermalManager.soft_pwm_amount_bed > 0
  ^
  sketch\src\feature\controllerfan.cpp:33:105: error: 'thermalManager' was not declared in this scope
  if (X_ENABLE_READ == X_ENABLE_ON || Y_ENABLE_READ == Y_ENABLE_ON || Z_ENABLE_READ == Z_ENABLE_ON || thermalManager.soft_pwm_amount_bed > 0
  ^
  sketch\src\feature\controllerfan.cpp:34:12: error: 'E0_ENABLE_READ' was not declared in this scope
  || E0_ENABLE_READ == E_ENABLE_ON // If any of the drivers are enabled...
  ^
  exit status 1

• ADVANCED_PAUSE_FEATURE broken:

  sketch\src\gcode\feature\pause\M125.cpp: In static member function 'static void GcodeSuite::M125()':
  sketch\src\gcode\feature\pause\M125.cpp:81:30: error: 'print_job_timer' was not declared in this scope
  const bool job_running = print_job_timer.isRunning();
  ^
  exit status 1

• PINS_DEBUGGING broken:

  ..... too much for pasting here .....

[RalphSch]

Another strange thing: The LCD does not initialize when the printer is powered on, it needs one reset and then it works fine.

[RalphSch]

Another double-bug: If I only activate CASE_LIGHT_ENABLE with CASE_LIGHT_PIN and MENU_ITEM_CASE_LIGHT disabled (default setting) then the code compiles fine but M335 gives this error:

M355
Error:No case light
... this is an missing or broken sanity check because there is no CASE_LIGHT_PIN default assigned in pins_RADDS.h.

Only activating CASE_LIGHT_PIN for pin reassignment gives this compiler error:

sketch\src\feature\caselight.cpp: In function 'void update_case_light()':
sketch\src\feature\caselight.cpp:37:44: error: 'USEABLE_HARDWARE_PWM' was not declared in this scope
if (USEABLE_HARDWARE_PWM(CASE_LIGHT_PIN)) {
^
exit status 1

Only activating MENU_ITEM_CASE_LIGHT gives this compiler error:

sketch\src\lcd\ultralcd.cpp: In function 'void lcd_main_menu()':
sketch\src\lcd\ultralcd.cpp:950:32: error: 'CASE_LIGHT_PIN' was not declared in this scope
if (USEABLE_HARDWARE_PWM(CASE_LIGHT_PIN)) {
^
sketch\src\lcd\ultralcd.cpp:950:46: error: 'USEABLE_HARDWARE_PWM' was not declared in this scope
if (USEABLE_HARDWARE_PWM(CASE_LIGHT_PIN)) {
^
exit status 1

[fiveangle]

Didn't this issue get fixed ?

[rafaljot]

No, not yet. @montycb said DELAY_20_NOP works for him but only after shielding wires. I have short wires 10cm. It doesn't work. Display is still dead.

[RalphSch]

I think we have to lower the spi speed, even with the 1Mhz on 16Mhz hardware there are sometimes problems with the cheap unshielded flat-wires usually used in all low price printers, so 1Mhz should be the maximum rate at least for the reprapdiscount full lcd ones.

[ejtagle]

I'll comment my experience here: I converted a RAMPS 1.4 to be compatible with Arduino due (essentially, powering the Ramps logic from 3.3v instead of 5v, and swapping pins A9<->A12, A10<->A13, A11<->A14,and then realized that by just powering the REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER with 5v, instead of 3.3v, the graphics display and SD should work (because the Arduino Due can't read anything from the display, all signals goes from the arduino to the LCD, so the logic levels are compatible. The only lines that return from the controller to the arduino are the SD card lines, and those are 3.3v.
Well, it has worked beautifully. The only thing i had to add was

define ST7920_DELAY_1 DELAY_15_NOP

define ST7920_DELAY_2 DELAY_15_NOP

define ST7920_DELAY_3 DELAY_15_NOP

And use the RAMPS_DUE board definition.

This is very interesting, because i have very long flat unshielded cables (50 cm) running from the Due to the controller, and there is no display corruption or read errors

So, i guess the level translator that is being used on RADDS / RAMPS-FD maybe is slow/weak and is unable to drive long cables reliably...

[JerryDurand]

Problems driving long cables can also come from drivers that are too
fast.  A fast signal into an unterminated line will lead to all sorts of
trouble.  You need a driver matched to the line, essentially no faster
(slew rate limited) than needed to get the signal through.

Faster is not always better.

On 10/02/2017 10:53 PM, Eduardo José Tagle wrote:

This is very interesting, because i have very long flat unshielded
cables (50 cm) running from the Due to the controller, and there is no
display corruption or read errors

So, i guess the level translator that is being used on RADDS /
RAMPS-FD maybe is slow/weak and is unable to drive long cables reliably...

--
Jerry Durand, Durand Interstellar, Inc.
www.interstellar.com
tel: [phone]
@DurandInterstel

[ejtagle]

Completely agree with you. Add to that there is no termination on the cables and you will soon have lots of problems ... :O

[JerryDurand]

On properly terminated CAT-5 wire* and using slew rate limited drivers
I've sent DMX-512 signals all the way around a sports arena with taps
for dimmers all along the way.  In theory the signal is good for about a
mile of wire.

• yes, CAT-5 IS approved for DMX-512, my name is in very fine print in
  the ANSI spec.  (I think I added a comma or two)  :)

On 10/02/2017 11:00 PM, Eduardo José Tagle wrote:
>

Completely agree with you. Add to that there is no termination on the
cables and you will soon have lots of problems ... :O

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/7687#issuecomment-333747645,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHfZY-16INoNWYZtDaiFWlfZYaYwSsl8ks5soc1ygaJpZM4PcMl1.

--
Jerry Durand, Durand Interstellar, Inc.
www.interstellar.com
tel: [phone]
@DurandInterstel

[boelle]

@rafaljot can you compile the latest bugfix 2.0?

[rafaljot]

I repeated test.

1. Repetier 1.0.4 (last dev) https://www.repetier.com/firmware/dev/index.php
2. General->Arduino Due with RAMPS-FD v2
3. User-Interface-> RepRapDiscount Full Graphic
4. Download, verify, upload using Linux+Arduino IDE 1.8.9

LCD with Repetier works!

1. Download last Marlin 2.0
2. #define MOTHERBOARD BOARD_RAMPS_FD_V2
3. #define REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER
4. Verify, upload using same Linux+Arduino IDE 1.8.9

LCD is dead:

[rafaljot]

@boelle I do not think that this problem is already solved

[boelle]

have you attached the 2 config files as a zip file? ie configuration.h and configuration_adv.h from latest bugfix 2.0.x

[rafaljot]

I downloaded full source

[boelle]

attach the 2 files here as a zip file so we can check that you have the correct config

you can not just download and compile, the config needs to be correct

[rafaljot]

@boelle I downloaded the last version , unzip into clear env and modified these two lines:

define MOTHERBOARD BOARD_RAMPS_FD_V2

define REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER

[boelle]

attach the 2 files as a zip file

[rafaljot]

Marlin configs.zip

[boelle]

will have a look a bit later, but no gurantee i can figure out what is wrong, but others might beat me to it

[rafaljot]

The question is Is there anyone here with working Arduino DUE + RAMPS-FD + RepRapDiscount Full Graphic ?

[rafaljot]

@montycb (DUE + RADDS) ?
@RalphSch ?

[boelle]

i was close but gave up as it would be to expensive to buil ad Ramps FD board

i got the re-arm and just put my old trusty ramps on top and i now have 32 bit without to much hardware changes, but i do have full graph display

could not find anything wrong with the config

[rafaljot]

@boelle re-arm is LPC. Due, DuetWifi are SAM . Completely different uC .
It is not RAMPS-FD issue.
I think it is general problem in Marlin with HAL for SAM

[ejtagle]

I have DUE + Ramps, I will try this, to see if there is an issue

[montycb]

OK, I tested the latest version and the display is not working.

I know that 7b78a20fb7ab6224e2f5c49b43d9c16a42015bd0 works fine, the commits after that don't compile, 9558962d5932222ce6e4bdb4073ca2b1e54a8fff is broken. So the problem has to be one of the commits between those two. It is probably this commit 456a0ee76b95ba428c8210a245d71f682b782909. It changed the Due Software SPI.

[boelle]

@ejtagle did you find an issue?

@thinkyhead do you have an idea what is wrong with this one?

[boelle]

@rafaljot i think the issue with u8glib has been solved, try and test again with latest 2.0.x

[boelle]

Lack of Activity
This issue is being closed due to lack of activity. If you have solved the
issue, please let us know how you solved it. If you haven't, please tell us
what else you've tried in the meantime, and possibly this issue will be
reopened.

[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.