Bugfix 2.0.x update

[p3p]

Fix some merge issues with include paths and macros, Fix builds with Arduino IDE for 8bit AVR, Adds SPI API platform stubs, they still need implemented, Tested (on Re-ARM) and Applied PR #7384 and #7381 with minor tweaks to some include paths.

[bobc]

The Travis failures appear to be all down to Neopixel library. That sort of library is going to be a headache for HAL porting, it has a lot of CPU specific stuff in it. The Adafruit Neopixel library is a good example of how not to do multi-CPU support, one big file with everything in which rapidly becomes an unmaintainable mess. At least if it finds a non-supported platform, it should say "unsupported platform", rather than try to compile for a default CPU.

The Fastled library seems to do the same thing, and also has support for more hardware, and a much cleaner architecture. However, we would still need to fork it or push new platform support upstream.

In the meantime, perhaps we should mark Neopixel as a non-supported feature for LPC1768.

[p3p]

There are currently only 2 platforms tested in Travis, AVR, and Teensy 3.5, the separation isn't very clear but it's the Teensy 3.5 test that is failing. I will try blacklisting the Neopixel library for that platform (as it's an Arduino platform it generally uses the Arduino libs).

[bobc]

Ok, I see. According to Paul, Adafruit Neopixel lib should work with Arduino 1.8.2 and Teensyduino 1.36. I don't know what versions Platformio pulls in.

Edit: Weird, if I try building with pio at command line on my PC I get the same Neopixel errors. It appears that the Nexopixel lib needs this patch https://github.com/adafruit/Adafruit_NeoPixel/pull/135, I can't see how else it could compile. I added that patch to Adafruit_Neopixel.cpp and it compiles, I haven't verified it runs correctly.

[fiveangle]

@Tannoo mentioned in #7271 that he had a PR ready to support these generic LEDs (not just NeoPixel) and may have been more generic/easier to support that the Adafruit/Printrbot NeoPixel PR #7340. He was just waiting for the "any minute now" layout re-org to get done, which ultimately took months instead of days, so this NeoPixel PR got merged instead.

Perhaps we need to seriously consdier reverting #7340 if there is a better option.

@Tannoo - do you have an old copy of your LED PR somewhere that others could look at it ?

[Bob-the-Kuhn]

I've just updated pins_RAMPS_RE_ARM.h and cardreader.cpp. Please include them in this PR. pins_RAMPS_RE_ARM & cardreader updates.zip

[Tannoo]

I believe I deleted that branch, but I can create another one.

[fiveangle]

Did you just implement the Adafruit library in a different way, or does it not use the Adafuit lib at all ?

[Tannoo]

Not Adafruit... FastLED.

[Tannoo]

Also, have to install the lib manually. I didn't do any auto installs like the current code does now.

[p3p]

I've just updated pins_RAMPS_RE_ARM.h and cardreader.cpp. Please include them in this PR.

@Bob-the-Kuhn, Pulled in your new commits, .. also blacklisted Neopixel for Teensy3.5 until it's fixed or replaced.

[thinkyhead]

Merged! I will leave the commits in bugfix-2.0.x alone while it continues to develop.

When the HAL is more stabilized, I will do the file re-organization all at once, and then we can go from there.

I'm anxious to install my Re-ARM in place of my RAMPS-based i3, but it has a character display. Fortunately, I have a spare RAMPS that I can plug into the Re-Arm and some spare RRD character displays that I can develop with, if no one else wants to focus on that area.

---

…And, I can also work on character displays for DUE.

[Roxy-3D]

I'm anxious to install my Re-ARM in place of my RAMPS-based i3 which has a character display.

Yeah.... I'm eager to bring up my Folger Tech with a Re-ARM, RAMPS and character based display too!

If we can just get the 20x4 LCD's to compile... (They don't even need to work.... Just compile...) I'll be helping with that!!!!

We are getting very close to having some real life printers running the current code base on 32-Bit !!!! I can almost 'smell' it!

[Tannoo]

There is an old character library available for Platformio... called "TextLCD".

[Tannoo]

Well...it's for ARM.

[Roxy-3D]

Yeah... But I don't think it is going to be that hard to get the current 20x4 LCD Library to go. If we can get it to compile... It isn't going to take much to get it to work.

[Tannoo]

I've been dragging files from the arduino stuff...this is snowballing on me.

[p3p]

@Tannoo Did you see #7401? I've added in LiquidCrystal though its untested, and wont work with SD I presume as you cant use hardware and software SPI on the same pins at the same time.

[Tannoo]

I guess I did not. I thought I was using your branch.

[p3p]

Ah sorry the LPC1768 branch was superseded by https://github.com/p3p/Marlin/tree/bugfix-2.0.x-dev because I thought renaming was a good idea at some point last night I don't remember. The bugfix-2.0.x is up to date atm though.

[Tannoo]

Ok.. I'll switch branches.

[Roxy-3D]

@Tannoo I think https://github.com/MarlinFirmware/Marlin/tree/bugfix-2.0.x has everything we need to start working on the 20x4 LCD code.

[Tannoo]

Ok. I will do a test run when I get home.

[Tannoo]

Btw, I haven't found anything, yet, that doesn't work on the RRFG.

[p3p]

Btw, I haven't found anything, yet, that doesn't work on the RRFG.

You're having trouble with the Full Graphic?, I'm not aware of anything broken with them (apart from the known corruption issue), I can't test on the 20x4 until its delivered but I have made sure there is actually spi traffic.

[fiveangle]

Ah sorry the LPC1768 branch was superseded by https://github.com/p3p/Marlin/tree/bugfix-2.0.x-dev because I thought renaming was a good idea at some point last night I don't remember.

Uh

@Tannoo I think https://github.com/MarlinFirmware/Marlin/tree/bugfix-2.0.x has everything we need to start working on the 20x4 LCD code.

@Roxy-3D - What is the branch that we should be working from ?

I was told it would be best not to work on bugfix-2.0.x because everything is still getting re-aranged. Is there essentially nothing available that isn't subject to deletion or major refactoring ? Or was #7390 and #7401 the "re-arranging" that was being done and now we can work from bf20x ?

[p3p]

Is there essentially nothing available that isn't subject to deletion or major refactoring?

If you want to do a PR you base on https://github.com/MarlinFirmware/Marlin/tree/bugfix-2.0.x if you want to keep up to date with what I'm doing https://github.com/p3p/Marlin/tree/bugfix-2.0.x-dev they are currently the same. I'm working on cleaning up the HAL API atm into clear API headers and then per architecture implementation for the major peripherals. I really shouldn't have started with SPI =).

[bobc]

A little bit of a plan would be useful!

Unfortunately, while the HAL API is changing, it effectively freezes everyone. Scott said he would wait until Chris has a refactored HAL API before doing file re-arrangement. If we have a well defined HAL API, let's call it v1.0.0, then that frees up people to work on specific HALs or application code in parallel.

We currently have 4 HAL implemented, that should be enough to get a good idea of how well the HAL API is working to provide platform independence, but not too many that changes to the HAL API causes a huge ripple of changes.

If Chris defines the "reference" HAL API in LPC1768, then I would happily volunteer to update the Due HAL accordingly, maybe others can chip in for other targets.

Whatever we do, it would be nice to know who is working on which area.

On 2 August 2017 at 15:16, Dave Johnson notifications@github.com wrote:

Ah sorry the LPC1768 branch was superseded by https://github.com/p3p/Marlin/tree/bugfix-2.0.x-dev because I thought renaming was a good idea at some point last night I don't remember.

Uh

@Tannoo https://github.com/tannoo I think https://github.com/ MarlinFirmware/Marlin/tree/bugfix-2.0.x has everything we need to start working on the 20x4 LCD code.

@Roxy-3D https://github.com/roxy-3d - What is the development branch that we should be working from then ???

I was told not to work on bugfix-2.0.x because everything is still getting re-aranged. Is there essentially nothing available that isn't subject to deletion or major refactoring ?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/pull/7390#issuecomment-319685993, or mute the thread https://github.com/notifications/unsubscribe-auth/AA7VR5ZKyx8b-5azExLpl539SOoLHCbvks5sUITXgaJpZM4OpL-m .

[bobc]

I really shouldn't have started with SPI =).

SPI is a little tricky because the Arduino API doesn't support multiple SPI busses so we are forced to extend that API if we are to support that.

Personally, I would leave the HAL API unchanged as much as possible and try to extend it in a backwards compatible way to avoid a lot of rework, but since Chris volunteered... :)

[p3p]

Unfortunately with the Re-ARM using 1 SPI channel for both the SD card and Display I needed to centralise that access, (I couldn't leave the display on software SPI), so I had to head down this road. I think it will be better in the end as long as I can figure out how to port the AVR over without using any RAM and having user configurable software channels ...

[Tannoo]

You're having trouble with the Full Graphic?

Not yet. I was stating that I have NOT found any issues with it. This is good news.

[Roxy-3D]

@Roxy-3D - What is the branch that we should be working from ?

while the HAL API is changing, it effectively freezes everyone. Scott said he would wait until Chris has a refactored HAL API before doing file re-arrangement. If we have a well defined HAL API, let's call it v1.0.0, then that frees up people to work on specific HALs or application code in parallel.

There is room for debate here... But my preference is we work off of the https://github.com/MarlinFirmware/Marlin/tree/bugfix-2.0.x branch unless that slows people down for some reason.

[bobc]

I think it will be better in the end as long as I can figure out how to port the AVR over without using any RAM and having user configurable software channels ...

Yes, I think that will be really quite difficult. Perhaps I am too lazy, but my philosophy was to keep the AVR code unchanged for the AVR HAL, and make the more powerful 32 bit HALs adapt to it, because they can afford to use a few more cycles and RAM. That approach worked quite well with the Due HAL I think.

But if you can find a way to avoid using more RAM and CPU on the AVR side, that will be great.

Unfortunately with the Re-ARM using 1 SPI channel for both the SD card and Display I needed to centralise that access

I think I would have introduced a function "select_SPI_channel (byte)", and then the existing code would work without change. On AVR that function would be a nop, on LPC1768 it could be used to select the channel.

[Tannoo]

... But my preference is we work off of the https://github.com/MarlinFirmware/Marlin/tree/bugfix-2.0.x branch unless that slows people down for some reason.

Currently too many errors for me to compile.

https://github.com/p3p/Marlin/tree/bugfix-2.0.x-dev <-- This compiles okay after a little tweaking.

[p3p]

What errors are you getting?, I just Cloned https://github.com/MarlinFirmware/Marlin/tree/bugfix-2.0.x, built Mega2560, Teensy32 fine, switched the Motherboard to BOARD_RAMPS_14_RE_ARM_EFB and built fine, (with default configs), then enabled RRD_GLCD and SDcard and built successfully on the 3 platforms again ..

[Roxy-3D]

I was building a clone of https://github.com/MarlinFirmware/Marlin/tree/bugfix-2.0.x yesterday for Re-ARM just fine. I was trying to get the 20x4 LCD to do something...

It doesn't even seem to initialize. I was going to start working through the different signals and make sure each of them can be toggled.

But it seems to build just fine...

[p3p]

Sorry Roxy it's another pin incompatibility issue, Re-ARM was really only designed with the Smoothieware feature set in mind :/ pins LCD-D5, LCD-D6 and LCD-D7 are all not connected. I'm playing with using some of the spares (Ethernet) but it would require more DIY modifications to the LCD controller connectors.

[Tannoo]

One main error was LiquidCrystal.h not found.

[Tannoo]

Let me get the specifics when Iget back to the house.

[Tannoo]

Okay...it must have been the location of the files. I downloaded a the current bugfix-2.0.x and loaded that into PlaformIO, set the MB to BOARD_RAMPS_14_RE_ARM_EFB, enabled REPRAP_DISCOUNT_SMART_CONTROLLER and it compiled with no issues. (ignoring the fact that the LCD just has lines 1 and 3 with solid blocks)

Then, I enabled FIX_MOUNTED_PROBE, AUTO_BED_LEVELING_UBL, and EEPROM_SETTINGS and compile fails. I got it to compile by changing these lines in G29_Mesh_Validation_Tool.cpp:

137:
  extern void set_destination_to_current() { COPY(destination, current_position); }
..
143 & 144:
    extern void sync_plan_position_e() { planner.set_e_position_mm(current_position[E_AXIS]); }
    extern void set_current_to_destination() { COPY(current_position, destination); }

[Tannoo]

No display library issues now... PlatformIO seemed to install it this time around.

I was using Git's local cloned copy.... now it's not.

[Roxy-3D]

Re-ARM was really only designed with the Smoothieware feature set in mind :/ pins LCD-D5, LCD-D6 and LCD-D7 are all not connected.

Do you have a schematic of the Re-ARM board? What I'm wondering is if we could add a few more wires that break out of the special cable. Right now there is one wire that is broken out to get 5 volts to the LCD Panels. Could we break out those three signals and put them on some other convenient pins on the Re-ARM board and then the 20x4 LCD's would work?

The trick would be to do it so it is easy for an arbitrary user to duplicate the modification.

[p3p]

UBL seems to have changed something since I did a quick hack to make it compile for Roxy, as for the REPRAP_DISCOUNT_SMART_CONTROLLER there is some good news and some bad news .. I just this minute got it working what seems like perfectly, you just have to rewire LCD D5 D6 and D7 to pins that are actually connected to something, I chose some easily accessible Ethernet pins (as that's not supported anyway).. I also had to fix some timing issues I'l make a PR for that later.

[Tannoo]

Could we break out those three signals and put them on some other convenient pins on the Re-ARM board and then the 20x4 LCD's would work?

I would think so.... but that would require some work to make the cables. May have to have some cables made for purchase. OR, and new adapter to accept the current cables.

[Tannoo]

Or, maybe Panucatt can come out with a Re-Arm v2 with the corrections. Or new pin mappings and retain the Ethernet.

[Roxy-3D]

Yeah... It is too bad all the signals aren't there... But for people that are buying a Re-ARM board, it isn't that big of a deal for them to buy a RepRap Graphics controller instead of a 20x4 LCD. I mostly wanted the 20x4 LCD just because I already have one mounted on my printer that I'm going to bring up the Re-ARM board on.

Also... My biggest beef with the RepRap Full Graphics controller is it puts a big CPU load on the processor. But with the ARM chips, that concern doesn't exist. So... Maybe the initial support of 20x4 LCD's isn't that important?

Or, maybe Panucatt can come out with a Re-Arm v2 with the corrections. Or new pin mappings and retain the Ethernet.

I think Panucatt would prefer to sell the X5 boards. But I think those only work with the Viki Displays. It may be possible to get them to put out a new design (either Re-ARM or X5) that supports the existing LCD Displays. Once we get the Re-ARM running... It will be more straight forward to get other LPC-1768 (or LPC-1769) boards going...

[p3p]

Maybe the initial support of 20x4 LCD's isn't that important?

Too late ;) its done on the firmware side, its just up to users to pick the pins and make a cable.

[Tannoo]

I ran into another issue. I enabled RGB_LED and left PRINTER_EVENT_LEDS enabled, compile failed:

Marlin\Marlin_main.cpp: In function 'void gcode_M109()':
Marlin\Marlin_main.cpp:7395:107: error: 'map' was not declared in this scope
const uint8_t blue = map(constrain(temp, start_temp, target_temp), start_temp, target_temp, 255, 0);

I got around this by creating a mapx in utility.cpp for now.

[Roxy-3D]

Too late ;) its done on the firmware side, its just up to users to pick the pins and make a cable.

Can you show us which pins on the cable need to be broken out? I was thinking I could use a razor blade and break those wires out and then solder a Dupont wire connector on to each of the wires.

I was thinking then I could easily plug the wires into what ever spare GPIO pin we decided to use to talk to the 20x4 LCD. And that wouldn't be that hard for a user to duplicate.

[p3p]

@Tannoo That's not surprising I've only got as far as supporting features my printer has, if you need to add more Arduino based functions they need to go into the Arduino wrapper (arduino.cpp/h) in the LPC1768 HAL implementation.

@Roxy-3D I'l figure out what needs to be done and post it here, I'm currently using my logic analyser probes to bridge the signals.

[Tannoo]

Ok.