Get Re-ARM stuff for LPC1768 over to 32-Bit-RCBugFix-new

[Roxy-3D]

This is all from @p3p 's work.

We don't want to forget about the LPC1768 stuff in 32-Bit-RCBugFix-new !

When the file & folder reorganization happens, it is important this
stuff is included!

[p3p]

@Roxy-3D This isn't necessary my LPC1768 branch is already based on my new.. new 32bit HAL branch (#7028) that @thinkyhead will merge before the reorganisation, don't worry about it being forgotten about I've been the one keeping the HAL up to date, the platforms and HAL are in separate branches to keep rebasing easy until the big refactoring. The platforms are self contained in their individual folders so have no effect on any other part of marlin and can be seamlessly merged at any time.

(The LPC1768 branch is very experimental so wasn't included in the main PR)

[Roxy-3D]

OK! Good to know!!!! (You can tell I really want the Re-ARM stuff ready to go!)

[p3p]

I'm trying ^^ I've only had the board about 2 weeks (getting it to the UK was expensive), for the last few days I've been working on removing mbed as a dependency and researching getting the usb working so I've unfortunately gone backwards a bit in functionality, temporary setback though.

[Roxy-3D]

Yeah... I would like to see us able to update the firmware via USB instead of messing with the SD-Card!
I also think we should fill out those undefined pins in the pinmap_re_arm.h file so that any pin on the RAMPS board is accessible using its ATMega-2560 pin number. The documentation at https://s3.amazonaws.com/cdn.freshdesk.com/data/helpdesk/attachments/production/1047536701/original/Re-ARM%20pinouts.pdf?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAJ2JSYZ7O3I4JO6DA%2F20170622%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20170622T232858Z&X-Amz-Expires=300&X-Amz-Signature=a1c9aae70a9d98e2c283c0159064ecee51d106a1791f944f3f76eaf82b00f1c7&X-Amz-SignedHeaders=Host&response-content-type=application%2Fpdf tells us what those missing port and pin numbers need to be. It is just a matter of updating the list you have to get rid of the {0xff,0xff} entries.

[Roxy-3D]

Incidentally.... I'm able to get code loaded and running on the Re-ARM board. But right now... It is just using your digitalWrite() function to blink LED's using the RAMPS pins.h file numbers. The LCD Panel still doesn't work... But now I'm ready to go figure that out.

[p3p]

yea the pinmapping is a work in progress I was just filling it in and adding the Defines as I needed them, I'm glad you've managed to get something working, it would be nice to know if Marlin is managing to boot all the way and your LCD is just not working (timing issue? ST7920_DELAY in HAL.h) or if its an issue during setup. (I've been working off that pdf, not all pins have a mapping though)

[Roxy-3D]

Well... a lot of stuff is working... I now have my LED blinking in the loop() function. And I had too long of a delay() specified and I watched the board shut down because of the watch dog timer... I'm kind of blind about what it is going on. But for sure, a lot of stuff is working. I'll try messing with the ST7920_DELAY tomorrow.

[Roxy-3D]

@p3p I still have LCD Panel problems... First I tripled the ST7920_DELAY's in HAL.h Still no splash screen.

But I do know the firmware is able to do some stuff with the LCD Panel. I added some code to check if the Encoder Wheel is pressed and if so, stop incrementing the LED's and instead chirp at the user. That does work... So at least the button side of the LCD Panel is there and working. And for that matter... The speaker works on the LCD Panel too.

void loop() {
static int i, j, k;
  pinMode( 3, OUTPUT);  // X-Min
  pinMode( 2, OUTPUT);  // X-Max
  pinMode( 14, OUTPUT); // Y-Min

      if (ubl_lcd_clicked() )
        chirp_at_user();
      else
        i++;

      digitalWrite( 3,  i & 0x01 );
      digitalWrite( 2,  i & 0x02 );
      digitalWrite( 14, i & 0x04 );
      delay(500);

[Roxy-3D]

@p3p Hey!!! My LCD is working. I was powering my board from a USB plug, and apparently, the 5 volts isn't passed through to the various 5 volt pins. It gets cut down enough in an attempt to regulate it that the LCD Panel didn't display anything. For now, I just jumpered the 5 volts past the regulator so I can still use the USB plug for power. But probably when I actually am using it on a printer it can get 12 volts from the RAMPS board.

[bobc]

@p3p Have you looked at https://github.com/ExploreEmbedded/Explore-M3 ? It's a fairly complete Arduino API for LPC1768, I've did some hacking to it to get USB working. I was working on LPCXpresso 1768 board, so should be similar.

[Roxy-3D]

Very cool! No, I didn't know about that. But a couple of things jump out... First, we can probably support the Re-ARM board on Arduino. That makes it easier for people that are moving from AVR boards to a Re-ARM. Probably... If we are careful with the code, we can compile (and load) on either PlatformIO or Arudino.

But the cool thing is with an extra switch, we can load the board from Arduino instead of messing with SD Memory cards. An official and working 32-Bit version of Marlin is getting closer and closer!!!

[bobc]

Explore-M3 is a package for Arduino, that was why I mentioned it.

[p3p]

@Roxy-3D I was really trying to think of something different between our hardware setups and that didn't even occur to me, (mine is powered from the hardware serial), I'm glad its working everything makes sense again.

@bobc That's good to know, using an Arduino implementation like that is definitely an option, I was intending to implement it at CMSIS level as far as possible but that was only by preference and to try and give a "generic" ARM template.

[Roxy-3D]

@p3p When you say "Hardware Serial" do you mean the UART connector close to where the LCD Panels split ribbon cable plugs in to get 5 volts? I need some kind of serial interface so I can see the SERIAL_ECHO() information.

What are you using to interface? (Can you provide an eBay link so I can order the right thing?) And where are you plugged into the board?

[p3p]

The 6 pin connector that comes out horizontally from the board, it's a standard FTDI compatible connector, (5V, GND, and UART), I mentioned this to you a few times when trying to help with the LCD, I probably wasn't very clear. https://www.sparkfun.com/products/9717 would be one option, the LPC1768 is 5V tolerant on most pins so you don't specifically need the 3.3V version (it still supplies 5V VCC).

[Roxy-3D]

Yes... You did mention it. And I started looking up FTDI and got overwhelmed. There were a lot of things I didn't understand. Like RS-232 is supposed to be +/- 12 volts but this was +5 volts and Ground. But all that aside... So I started using LED's to see if I could get any code loaded on the board. And to see if I could tell what was happening.

Do you display the output of that USB cable inside of PlatformIO ? I see a PlatformIO-ide-terminal package that I can install.

[p3p]

There is a button (second to bottom) on the left that looks like a plug, it opens a serial port terminal after choosing port and baudrate, you don't need to install anything else.

[Roxy-3D]

Hah!!!!! THANKS!!!! Cable is on its way.

[Roxy-3D]

@Bob-the-Kuhn I know I used to have your email address. And I used to have your shipping address. But I can't find either right now. Can you email me your shipping address and then I'll have both in one place? Thanks!!!

[p3p]

one of the first things I'll do is put in code that uses a file on the SD-Memory card for EEPROM simulation

@Roxy-3D Actually, that's already working, along with the USB stack (much tidying and reorganising required), although I've somehow managed to go backwards with the graphical display(fixed). The work continues although there are parts I need to change in the HAL API (such as the persistent store API I added and hooked into Marlin settings, the already defined macros made that simple), with the big merge pending I don't want to do that too much though.

oh if you test this don't access the SD card over USB at the same time as writing the eeprom, I still need to implement the auto disconnect on local filesystem mount, also its probably worth saying don't have anything on the SD card you care about (disclaimers ect ect)

[Bob-the-Kuhn]

Bob Kuhn
1034 Wisteria Trail
Austin, TX 78753
bob.kuhn@att.net

[thinkyhead]

@Bob-the-Kuhn I see that you are only a 10 minute drive from where I live, on Dessau Rd. We should get together sometime to get the HAL and 2.0 branch hammered out. I've got all the ducks in a row, but it would be good to be able to bounce ideas around. I also have several boards to test on, including RAMPS, Due, and Re:Arm, plus one or two extra RAMPS shields. And, Saturday is "Software Saturday" at the local maker-space, just a mile from here.

[Bob-the-Kuhn]

Bouncing ideas off me?!!? That's funny. I appreciate the compliment.

I'm hoping to be helpful but I expect it'll probably in the area of helping keep the 8 bit stuff off your back. Don't be afraid to assign things to me.

The wife's making threatening remarks about putting some drywall up in the bathroom and shopping for tile.

I'm sure I can drop into the maker-space sometime Saturday but I have no idea when. Give me a shout at (+++) +++-++++ & I'll see if can meet you there.

Now to find out what a maker-space is.

[Bob-the-Kuhn]

@Roxy-3D - can you provide a brief startup sequence for getting the P3P on my Re-ARM with RAMPS1.4?

[p3p]

@Bob-the-Kuhn It should be relatively painless

0. Swap out controller
1. Install PlatformIO IDE
2. Clone https://github.com/p3p/Marlin.git and Checkout 32bit-bugfix-1.1.x-LPC1768
3. Open the PlatformIO project from the PlatformIO Home screen (Browse to the folder containing platformio.ini and click OK, it kinda odd you don't select anything)
4. Click PlatformIO->Run other target.. (or press F7), Scroll to the bottom of the list to build for Re-ARM
5. Copy Marlin/.pioenvs/Re-ARM/firmware.bin to sdcard and put into Re-ARM then reset.
6. Marlin boots flawlessly and everything works. (End user experience may vary)

This branch is under active development I usually only push to github when its working but no guarantees, I'm currently in the middle of reorganising and pondering if its possible to hide folders from the Arduino IDE (I have never really used it), wrapping entire frameworks in ifdefs is not really feasible.

Apart from the horrible mess the main omission from the current build is character displays, otherwise it should support baseline Ramps 1.4 features.

[Roxy-3D]

can you provide a brief startup sequence for getting the P3P on my Re-ARM with RAMPS1.4?

Once you grab p3p's latest branch at: https://github.com/p3p/Marlin/tree/32bit-bugfix-1.1.x-LPC1768
the biggest (most complicated) is to get PlatformIO installed. It is some add-in that runs inside of the Atom text editor.

You can start the install process here: http://platformio.org/get-started/ide?install=atom

I forget... But there is some add-in or package that you have to install and restart Atom a couple times to get it to stick. And it is a little bit less than intuitive to get P3P's branch loaded into it as a project. But once that happens... You should have a screen that looks like this:

You then need to go to the very lower left corner and select PIO-Build-ReARM out of the list. And with that selected you can go to the far middle right 'build' button. It looks like a lightning bolt.

At the end of a successful build you should get something that looks like:

Calculating size .pioenvs\Re-ARM\firmware.elf
text data bss dec hex filename
137900 2444 5040 145384 237e8 .pioenvs\Re-ARM\firmware.elf
Building .pioenvs\Re-ARM\firmware.bin
[SUCCESS] Took 329.44 seconds

Hunt down the firmware.bin file. Put it on a FAT-32 formatted SD-Memory card. (I believe it needs to a 4GB or bigger card but I could be wrong on that.) And power up or reset the Re-ARM board. If the firmware got updated on the board, the .bin file will be gone and it gets renamed to firmware.cur

At that point... You should see the Marlin logo and splash screen if you have a Graphics LCD Panel plugged into the RAMPS board and have the magic 5 volt ribbon cable plugged in the right place.

[p3p]

But there is some add-in or package that you have to install and restart Atom a couple times to get it to stick

@Roxy-3D that's interesting there shouldn't be any extras needed, will have to reinstall from scratch to make sure I'm not forgetting something, Have you had any luck with the new USB serial and Mass storage btw, I havn't had time to test it on windows yet (OK I keep forgetting).

[Roxy-3D]

that's interesting there shouldn't be any extras needed,

I don't remember... But I was following a Help Page describing the steps. And there was some version problem or something. It might have even been the PlatformIO-IDE add in that had the version problem. I don't remember. But there was some package it was telling me to install and you had to do some funny things to get it to stick. And the help file did warn about that.

I have not tried the USB Serial or Mass storage yet. Do you mean 'Persistent Storage' ? And when you say 'USB Serial', does that mean PronterFace can receive SERIAL_ECHO() messages now over the USB Cable?

[Tannoo]

I didn't have to....The homing works, because it thinks all of the limits are on. lol

[Tannoo]

I didn't change any limit logic in configuration.h.

[Tannoo]

x_min: TRIGGERED
y_min: TRIGGERED
z_min: TRIGGERED

[Tannoo]

http://www.keil.com/forum/59200/ could be the start of building your own library for the 20x4 displays.

[Tannoo]

Or, am I 29 steps behind there? lol

[teemuatlut]

So I just (finally) received my Re-ARM and I got to say, that's one sexy looking board. Did they recently update the color because I don't remember it being mat black in the pictures before.
Anyway, is there a quick setup guide or something to get me up to speed? And what's the latest on SPI (for TMC steppers)?

[p3p]

SPI on Re-ARM is currently limited to the single Hardware channel that is controlling the SDcard and display (I need to fix AVR before I can move back to LPC1768), how do TMC steppers connect to ramps? if they need a library I'm afraid they are unlikely to work for a while.

[teemuatlut]

TMC2130 is with step/dir/en and SPI CLK, MOSI, MISO. They do need a library and that uses the general SPI library plus the digitalWrite function.
TMC2208 is configured with UART.

[p3p]

If only the rest of Marlin used this library you speak of I would have a single point of abstraction, I assume it must have proved too slow.

[bobc]

I've been looking more closely at the changes, and noticed in ultralcd_st7920_u8glib_rrd.h it now reads:

#define ST7920_CS()              { HAL::SPI::enable_cs(LCD_SPI_CHANNEL); U8G_DELAY();}
#define ST7920_NCS()             { HAL::SPI::disable_cs(LCD_SPI_CHANNEL); }
#define ST7920_SET_CMD()         { HAL::SPI::write(LCD_SPI_CHANNEL, 0xF8); U8G_DELAY(); }
#define ST7920_SET_DAT()         { HAL::SPI::write(LCD_SPI_CHANNEL, 0xFA); U8G_DELAY(); }
#define ST7920_WRITE_BYTE(a)     { HAL::SPI::write(LCD_SPI_CHANNEL, (uint8_t)((a)&0xF0u)); HAL::SPI::write(LCD_SPI_CHANNEL, (uint8_t)((a)<<4u)); U8G_DELAY(); }
#define ST7920_WRITE_BYTES(p,l)  { for (uint8_t j = l + 1; --j;) { HAL::SPI::write(LCD_SPI_CHANNEL, *p&0xF0); HAL::SPI::write(LCD_SPI_CHANNEL, *p<<4); p++; } U8G_DELAY(); }

Previously, this code used carefully optimised functions, customised for specific AVR boards. They would all now use a generic function. This would seem to be a significant regression on the AVR implementation.

I'm a bit worried we're compromising the AVR code in order to fit in the new HAL for Re-ARM.

[Roxy-3D]

Can this be compensated by just reducing the size of U8G_DELAY() ?

[p3p]

That was my concern as well and why I haven't managed to implement the AVR code yet, I'm trying to make sure I don't impact it. I cannot run software SPI and hardware SPI on the same pins without a reinitialisation on every chip select so intercepting the calls at this point was the cleanest solution, as long as I do it right it should not cause any degradation in performance on AVR. I am watching the signal timings closely.. but if there is a better way I'm open to suggestions.

[teemuatlut]

If only the rest of Marlin used this library you speak of I would have a single point of abstraction, I assume it must have proved too slow.

Do you mean the TMC library or the SPI library? I could inherit and override the communication method in the TMC library to use functions that are compatible with Re-ARM.

[bobc]

You are assuming that we must use hardware SPI on LPC1768... we could use software SPI on LCP1768.

If the impact of optimising the LPC1768 performance is to make the AVR code less optimal, that is not the right tradeoff IMO. Make the fast chip a bit slower, rather than making the slow AVR slower. The timings for LCDs on AVR have been tested and tuned on several AVR boards, changing that code means re-verifying all those boards.

My suggestion is that we keep the AVR software SPI behaviour for now, and study how to replace it for a V2 API. There are several people eager to get stuck in with testing on Re_ARM, STM32 ports etc, we don't necessarily need a fully optimised LPC1768 implementation in the first pass.

[bobc]

Can this be compensated by just reducing the size of U8G_DELAY() ?

The "old" code already adapts for fast CPUs ,

#if F_CPU >= 20000000
  #define CPU_ST7920_DELAY_1 DELAY_0_NOP
  #define CPU_ST7920_DELAY_2 DELAY_0_NOP
  #define CPU_ST7920_DELAY_3 DELAY_1_NOP

That code works for Due, Teensy35 and would also work for LPC1768. I don't really see why we need to change it for Re-ARM, at least not now.

[p3p]

@bobc I'm happy to have the SPI changes removed. I can sort out a PR for that.

@teemuatlut I meant the SPI library, it's not used by Marlin at all (as the current discussion shows ;))

[p3p]

@bobc yes I'm pretty well versed in how Marlin handles SPI communication at this point ^^, those values need to be quite large to get a stable software SPI transfer to the GLCD on the LPC1768, at least in my testing.

[teemuatlut]

I meant the SPI library, it's not used by Marlin at all

Well that's not quite right (digipots, tmc26x, tmc2130, l6470), but I think I'll let you handle the more important stuff and get the SPI running and I'll worry about fitting the TMC steppers into everything once things settle down a bit first =)

[Bob-the-Kuhn]

I've been playing with my Re-ARM and a VIKI2 display & so far I've come up with a mangled mess and a controller that freezes. Time to step back and ask for help/advice.

Should I wait until the SPI stuff is all sorted out?

My approach was to turn off the SD card and use the soft SPI version of the U8G call:
U8GLIB_NHD_C12864_2X u8g(DOGLCD_SCK, DOGLCD_MOSI, DOGLCD_CS, DOGLCD_A0, 255 );

As I wandered about the U8glib-ARM_ID1691 code it looks like I needed a lot of the code that was wrapped with '#if AVR' . I eventually gave up trying to tease out what I though I needed.

Maybe the best approach is to re-write u8g_dev_st7565_64128n.c specifically for the Re-ARM similar to ultralcd_st7920_u8glib_rrd.h

[fiveangle]

@Bob-the-Kuhn - can you push #7421 and #7422 when you have a moment.

[p3p]

@Bob-the-Kuhn I fixed the SPI .. by that I mean I reverted all my changes, the Re-ARM now only supports software SPI on the user SPI channel. The software timings for the GLCD need tuned, currently only 400KHz as I got corruption any faster, it was running at 5(ish)MHz on hardware so something odd there. I will have a less stressful time implementing the SPI API now its not partially implemented in the live branch ^^ although there are other things I should probably do first.

[Bob-the-Kuhn]

@p3p - definitely do what you think is most important. We have one display that works fairly well so displays are a low priority.

[Roxy-3D]

definitely do what you think is most important. We have one display that works fairly well so displays are a low priority.

Actually... I have the 20x4 LCD Code p3p did going on my Folger Tech. So far, I haven't seen a problem with it. But once I get UBL to compile, that will be the real test because the LCD Mesh Editing does a bunch of custom characters and really beats on the display.

[Tannoo]

I don't have my ReArm on my printer, but I got UBL to compile and the LCD UBL options looked good... even the map.

[Tannoo]

For both the graphic and the 20x4.

[Tannoo]

This is what I changed in G26_Mesh_Validation_Tool.cpp:

-  void set_destination_to_current();
+  extern void set_destination_to_current() { COPY(destination, current_position); }

-    void sync_plan_position_e();
-    void set_current_to_destination();
+  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); }

[Roxy-3D]

That's it??? I've got to debug a probe problem that is keeping me from homing the Z-Axis. But then I'll be bringing UBL up on a 20x4 LCD Display. So I'll do those edits!!!