LPC port of RepRapFirmware

There is now a forum at duet3d.com to discuss RepRapFirmware on non-Duet electronics. See [www.duet3d.com]. Feel free to use it, or to continue the discussion here. Or both.

Edited 1 time(s). Last edit at 03/31/2018 07:41AM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

There are two things in the new v2-dev branch of RRF in github that may be useful to you for your LPC port:

- I've added a spreadsheet to help calculate what is using RAM, to make it easier to see where savings can be made;
- I've changed to using newlib-nano instead of regular newlib, and our own strtod function instead of the library one. Between them this has saved around 3K of RAM.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

As much shit as you sometimes get dc42 it's nice to see you still try and help out documenting and providing resources to those trying to port RRF for other boards. So just wanting to say thanks.

Edited 2 time(s). Last edit at 04/04/2018 08:25PM by cyris69.

Quote
dc42
There are two things in the new v2-dev branch of RRF in github that may be useful to you for your LPC port:

- I've added a spreadsheet to help calculate what is using RAM, to make it easier to see where savings can be made;
- I've changed to using newlib-nano instead of regular newlib, and our own strtod function instead of the library one. Between them this has saved around 3K of RAM.

Great!! I'll check those out. 3K would be a big saving here.

I'm just getting this port going on my re-arm. Web control works - nice job on getting ethernet running!
My first hurdle is figuring out what the timing requirements are for thb6128 drivers. Anyone know? I've been scouring the interwebs for the last half hour without any success.

I think the THB6128 is a LV8729 in an upside down package (thermal pad on top instead of underneath). In which case you need T0.5:0.5:0.5:0.5 in the M569 commands.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
sdavi

Quote
dc42
There are two things in the new v2-dev branch of RRF in github that may be useful to you for your LPC port:

- I've added a spreadsheet to help calculate what is using RAM, to make it easier to see where savings can be made;
- I've changed to using newlib-nano instead of regular newlib, and our own strtod function instead of the library one. Between them this has saved around 3K of RAM.

Great!! I'll check those out. 3K would be a big saving here.

The latest v2-dev sources also include a custom vsnprintf implementation (based on the FreeRTOS one with floating point support added), which saves a little more RAM.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
dc42
The latest v2-dev sources also include a custom vsnprintf implementation (based on the FreeRTOS one with floating point support added), which saves a little more RAM.

Great. Using newlib-nano and the new strtod saved an extra 1.5K of memory. Bringing in the new vsnprintf has saved another 260 bytes (as well as reduction of the max stack usage).

If you feel like recompiling newlib, you could save some more RAM by removing unnecessary bits from struct _reent. When I did the conversion to FreeRTOS I tried the FreeRTOS option to allocate a struct _reent for each task, which supposedly makes newlib reentrant. Unfortunately that made the task structures huge, so even though I had only 5 tasks I ran out of memory. When I looked at _reent I found it had lots of stuff we don't need, such as a pile of data for handling I/O to/from stdin/stdout/stderr. That's why I wrote the threadsafe versions of strtod and printf.

I haven't checked exactly how big struct _reent so I suggest you check it before doing a lot of work to shrink it. I suspect it's not far short of 1Kb, perhaps more. Newlib allocates one statically.

Another thing to watch for is that you don't have initialised read-write data that can be made read-only. I checked all the initialised read-write data in the linker address map a few weeks ago, but something may have crept in since then.

HTH David

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Thanks, dc42. Those timings seem to work fine.

I have motors and XY endstops working now. But I am running a BLtouch connected to the Zmin endstop and the servo to D4 (pin 1.18) on the RAMPS (and Re-Arm) and can't figure out if that pin is set up. I tried to find the mapping in the header files, but I'm not very familiar with RRF (nor am I a programmer). Is there a way I can connect it with the compiled firmware or do I need to change something and re-compile (which I'd have to set up)?

Also, I have a PT100 with e3d amplifier. I'm guessing there's no easy way to get that working... or is there?

You'll need to ask sdavi about the pin mapping for bltouch.

PT100 with analog amplifier is not supported by RRF because it supports the more accurate digital interface boards instead. If the LPC port implements the usual sharing of the SPI bus that RRF normally does, then you can add an external MAX31865-based digital PT100 interface board. These are available inexpensively on ebay etc.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Hey dc42, might I ask for your help understanding what's going on with loading mesh grid? It seems that you need to call the heightmap in order for it to get used. So I place G29 S1 in my start script after G28. However, I get this error.

Error: G29: Failed to load height map from file heightmap.csv: number expected at line 3 column 1

This is the height map as well: [www.mediafire.com]

Edited 1 time(s). Last edit at 04/12/2018 10:16PM by cyris69.

I fixed a similar problem in the 2.0dev branch recently. Make sure you are using the latest versions of Grid.cpp and strtod.cpp.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Thanks, I haven't downloaded any source to build from. I'm sure sdavi will see this.

Quote
digi2life
Thanks, dc42. Those timings seem to work fine.

I have motors and XY endstops working now. But I am running a BLtouch connected to the Zmin endstop and the servo to D4 (pin 1.18) on the RAMPS (and Re-Arm) and can't figure out if that pin is set up. I tried to find the mapping in the header files, but I'm not very familiar with RRF (nor am I a programmer). Is there a way I can connect it with the compiled firmware or do I need to change something and re-compile (which I'd have to set up)?

Also, I have a PT100 with e3d amplifier. I'm guessing there's no easy way to get that working... or is there?

D4 maps to P1_18 which is hardware PWM capable (channel 1), however, there is also only 1 PWM timer on the LPC (with 6 channels) that means all PWM channel pins run at the same frequency. So if the BLTouch is happy to run at a higher frequency (i think the hotend heater pins are running at 250Hz?) then it may work. Running M122 will also print out the current Logical Pin mappings of the spare/special pins, which D4(P1_18) is 65.

There are also 2 spare Timers available to us if that doesn't work. The timers do have a feature where they can output to a pin (toggle, output high or output low) when there is a match. There is only one match per external output, so an interrupt would still need to be triggered on the period match to set the pins high (or low). Looking at the manual:
Timer2 has mat0 on P4_28 and mat1 on P4_29
Timer1 has mat0 on P1_22 and mat1 on P1_25
Timer0 has mat0 on P1_28/P3_25 and mat1 on P1_29/P3_26

This is currently not implemented though. Some pins may not be broken out (i haven't checked them all on all the boards), but Timer0 looks like a good candidate for this as 3_25 and 3_26 are available on the re-arm, which could give 2 servo (or 2nd PWM at the same freq) outputs at the cost of an interrupt firing every 20ms, and selecting mat pairs on the same port can also use the fast parallel write which would make it a very short interrupt.

Quote
dc42
You'll need to ask sdavi about the pin mapping for bltouch.

PT100 with analog amplifier is not supported by RRF because it supports the more accurate digital interface boards instead. If the LPC port implements the usual sharing of the SPI bus that RRF normally does, then you can add an external MAX31865-based digital PT100 interface board. These are available inexpensively on ebay etc.

At the moment there is still no support compiled in for SPI thermocouples. The ASF license doesn't allow source code to be distributed and used on non-atmel chips which is why the SharedSPI is not used as is - a wrapper to look and behave like SharedSPI is probably possible. However, I also don't have any SPI thermocouples so I couldn't even test if it was working or not, so I've left it out.

Quote
cyris69
Thanks, I haven't downloaded any source to build from. I'm sure sdavi will see this.

I've updated to the latest strtod and uploaded new binaries. I haven't included the new grid.cpp as it wasn't a straight drop in, so hopefully the new strtod fixes it for now - grid loads ok for me here.

The new Grid.cpp avoids pulling in the sscanf function, which in turn pulls in strtod from the library. Using it instead of the old one may save some stack or RAM when you load a height map.

Edited 1 time(s). Last edit at 04/13/2018 09:35AM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Woohooo! I'm probing. M122 is my new favorite thing - I thought something like that might exist but I sure couldn't find it yesterday. I also tried switching all the 60s but nothing triggered the probe. I had to remove the I-1 inversion to get the probe to work. It's a lot easier to debug when you know you have the right pin! Thanks for getting back to me, sdavi.

deployprobe.g:

M280 P65 S10

retractprobe.g:

M280 P65 S90

and my z-probe section of config.g:

; Z-Probe
M574 Z1 S2                                ; Set endstops controlled by probe
M558 P9 X0 Y0 Z1 H5 F200 T2000            ; BLTouch specific
G31 X-26.5 Y-1.5 Z.9 P25
M557 X5:295 Y5:195 S40                  ; Define mesh grid

And as for my PT100 issue, I just ordered a cartridge thermistor to replace it. I'll have that later today so I can continue my transition to RRF greatness.

That took care of it

Quote
sdavi

Quote
cyris69
Thanks, I haven't downloaded any source to build from. I'm sure sdavi will see this.

I've updated to the latest strtod and uploaded new binaries. I haven't included the new grid.cpp as it wasn't a straight drop in, so hopefully the new strtod fixes it for now - grid loads ok for me here.

Fwiw SharedSPI is about 50% code that I wrote. It's just a wrapper around some SPI transfer functions to let you configure the speed, SPI mode, CS pin etc. and save them in a struct for future use.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

I've been using this firmware on the Re-Arm for the last couple weeks and it's been great except for 2 network issues I'm having. There are times when I just can't get a connection to the web interface and have to reboot/reset the board multiple times until it decides to cooperate again. Usually, this is when first connecting to the board upon startup of the machine, but I've also lost the connection occasionally after the board is connected. is there a good way to diagnose this problem?

The second issue just began last Friday. When I attempt to view the g-code file directory through the web interface, the board disconnects after a few seconds (see attached image for a note on the file icons). I was still able to play files if I was fast enough to get them started before the disconnect. If I don't navigate to the g-code file tab, I have no issues. The config file editor works perfectly fine.
I tried a different sd-card and still had the same issue. Now that I'm writing this, the issue appears to be gone. I was able to upload a file and view the list with no issues.... so that's weird.

Quote
digi2life
I've been using this firmware on the Re-Arm for the last couple weeks and it's been great except for 2 network issues I'm having. There are times when I just can't get a connection to the web interface and have to reboot/reset the board multiple times until it decides to cooperate again. Usually, this is when first connecting to the board upon startup of the machine, but I've also lost the connection occasionally after the board is connected. is there a good way to diagnose this problem?

The second issue just began last Friday. When I attempt to view the g-code file directory through the web interface, the board disconnects after a few seconds (see attached image for a note on the file icons). I was still able to play files if I was fast enough to get them started before the disconnect. If I don't navigate to the g-code file tab, I have no issues. The config file editor works perfectly fine.
I tried a different sd-card and still had the same issue. Now that I'm writing this, the issue appears to be gone. I was able to upload a file and view the list with no issues.... so that's weird.

Yes the second issue is a known issue. From what I can tell it is when it attempts to scan all the gcode files in the gcode directory (for each file making a request which the firmware parses the file to extract layer height, etc etc) and then the status update request also fails which causes the disconnect - likely a side effect of only 1 listener. I think the web gui caches that data and if the gcodes are small enough, 1 by 1 it gets cached until its working again after each re-connection, however if the gcode is large enough it will never finish before the disconnect. At the moment, the solution is to delete the files in gcodes directory. The web gui probably needs a few mods to work with the single http listener we have on this port. I haven't been able to look into it as i needed my smoothieboard back on my CNC at the moment and my azteeg x5mini doesn't have networking.

As for the first issue, connecting with the USB cable and running M122 might help to see if its getting an IP address or not assuming your using DHCP, might help to narrow it down.

I've currently been working on the sharedSPI to get the SPI thermocouple sensors up and running. The SharedSPI is working with a external SDCard and LCD both running together so its looking good so far. Ive also included the U8G2 library, and finished writing the U8G2 sharedSPI interface, so hopefully adding SPI LCDs supported by U8G2 will be straight forward. Its currently working on my Viki2.0 LCD and plan to test it also on the RRD full graphic LCD which i have laying around. Still a work in progress

Excellent work sdavi!

Personally i'm not interested in any form of networking, just a 128x64 display with control knob, and reading files from the removable SD card would do me fine (just as my printer has always worked with RAMPS/Marlin, RAMPS/Repetier, Re-Arm/Smoothie and Re-Arm/Marlin 2.0).

The RepRapFirmware page says that it is starting to add support for 12864 displays, does anyone know how mature this is? Have you tried RepRapFirmware on Re-Arm with a RepRapDiscount 12864 full graphic display?

Quote
nebbian
Excellent work sdavi!

Personally i'm not interested in any form of networking, just a 128x64 display with control knob, and reading files from the removable SD card would do me fine (just as my printer has always worked with RAMPS/Marlin, RAMPS/Repetier, Re-Arm/Smoothie and Re-Arm/Marlin 2.0).

The RepRapFirmware page says that it is starting to add support for 12864 displays, does anyone know how mature this is? Have you tried RepRapFirmware on Re-Arm with a RepRapDiscount 12864 full graphic display?

Just had a look today and there has been some updates in DC42's V2.0 branch on the LCD support since I last checked. I copied the LCD files into this project and was able to get my RepRapDiscount Full Graphic LCD connected to my Azteeg X5 mini to display some test menu items from a file, so it's progressed a fair way already - I'll play around with it a bit more later after I've wired up the encoder. When its finished in the V2.0 branch I'll be look at including it here.

Edited 1 time(s). Last edit at 06/27/2018 05:50AM by sdavi.

Good stuff Sdavi, I look forward to hearing about your progress :-)

For my mind, the Re-Arm is the perfect board to upgrade from RAMPS. It basically works the same as we're used to, and if we could get RepRapFirmware working then that would truly be excellent bang for buck.

I've got an AZSMZ board which uses an LPC1768 and would like to try getting this RRF port onto it. Ideally, the AZSMZ 12864 LCD/Controller that was bundled with it would be functional as well.

What has to be done to add support for another board? Looks like I'll need to add a pin mapping in the variants folder and change Pins_LPC.h to accept the new mapping as an option; is there anything else that needs to be tweaked?

Quote
AlexY
I've got an AZSMZ board which uses an LPC1768 and would like to try getting this RRF port onto it. Ideally, the AZSMZ 12864 LCD/Controller that was bundled with it would be functional as well.

What has to be done to add support for another board? Looks like I'll need to add a pin mapping in the variants folder and change Pins_LPC.h to accept the new mapping as an option; is there anything else that needs to be tweaked?

Great! Would be good to get some configs for the other LPC boards out there. Looking at the AZSMZ online, looks like it has pluggable drivers so best bet would be to copy the rearm variant config and update the pinouts to suit. There is also a few extra spots in Platform.cpp to set the new boardname etc in the following functions:

void Platform:: SetBoardType(BoardType bt)
const char* Platform::GetElectronicsString() const
const char* Platform::GetBoardString() const

And in Platform.h update

enum class BoardType : uint8_t

If using the 1.21 version, in Platform.cpp also update the UpdateMotorCurrent function to avoid attemping to set the digipots as with rearm.


BTW, 1.21 is no longer updated, as there is a new RepRapFirmware V2 (RTOS) version. I've been working on porting the V2 RTOS for LPC for a few weeks now so if you want to work off the latest (and very experimental at this stage) look at the v2-dev-lpc branch. Soon, maybe this or next week, I will be uploading the new LPC core for version 2 which will also have all the makefiles etc I use for building and testing included.

For those following this thread, nearly all the time has been spent getting networking support for the new V2 RTOS version. It's now using FreeRTOS+TCP for the networking instead of Lwip. Along with other tweaks, upload speeds are now a lot faster and I've been using the latest DWC version as well which seems to work better with 1 http listener and many of the previous issues seem to have now been resolved. There is currently about 3.5K of never used RAM on the networking version, so hopefully it can continue with future updates for a while yet.

What's the current state of the v2 branch? If it's able to run a full print I'll try it otherwise I'll clone 1.21 first.

How is board selection done in RRF? In Marlin it's done by defining the motherboard in the config but I don't see something similar here. Also, does RRF use the onboard SD reader or the reader on the LCD controller?