RepRapFirmware 3.0 port for LPC1768/9 based boards

I've just uploaded an experimental RepRapFirmware Version 3 beta for LPC . There have been a lot of changes, so those brave enough to try it should do so with caution.

Those upgrading from RRF2 will need up update their config files (see changes required for RRF3).

I have also been modifying the RepRapFirmware Configurator for use with the LPC port and RRF3 (only a few boards have been added so far) - this is still very experimental so carefully check the config generated (especially the new RRF3 config options). It now supports driver timings, LCD configuration etc. The LPC Configurator will also generate a board.txt configuration file as well to make it easier to configure. LPC RRF Configurator page

LPC Updates

RRF3 now allows selecting pins used for heating, fans, thermistors etc from GCode (see above link) using the labels written on the silk screen on the board. There have been a lot of options removed from board.txt either as part of RRF3 or to make configuration easier (more details here).

Ensure when configuring pins in RRF3 to not use the wrong inversion when setting heater pins, as this would mean that the heater would turn on when the firmware thinks it's off and vice-versa.

To support board silk screen labels in the LPC port, a new board.txt entry called "board" is used to load the correct labels. Currently, the following values are accepted: smoothieboard, rearm, mkssbase_1.3, azsmzmini, biquskr_1.1, biquskr_1.3, azteegx5mini_1.1 and generic. If "board" is missing then it will default to "generic".

Known boards also have default values for the the stepper dir/en/step entries and if current control is supported by i2c, so those values no longer need to be specified in board.txt, unless you wish to assign different pins - if there is no board.txt entry for steppers then the board defaults will be used. The "generic" board option has no defaults and only use the port.pin format in gcodes.

Where possible, the labels as written on the board silk screen have been used, and where there are none on the board, the labels from the schematics are used. For boards, such as ReArm etc, that use the i.e x-/x+ labelling for endstops will need to use xmin/xmax due to the way RRF handles the labels. If no labels exist on the board/schematics then the standard port.pin format is used, ie. 2.0. The pin.port format is also checked after the silk labels as a backup or if users wish to stick with that format. Supported labels assigned for each board can be viewed here: [github.com] (as I don't have most of those boards I have relied on information from the web for the labelling so there may be errors)

Note: that the pin settings within board.txt must still use the existing port.pin as the pin labels are currently only supported RRF3 GCodes.

Endstops are now defined in GCode in RRF3 as well, removing the need to define them in correct order in board.txt

PWM and Servos

PWM has had a big update in the LPC port - take extra care when using this version. Heaters and Fans all now use a free-running microsecond timer to generate PWM. It now also allows you to specify different frequencies (within reason) for each pin instead of the previous restriction of only 3 frequencies. PWM pins no longer need to be pre-defined in board.txt

Servos will preference the HardwarePWM pins where possible, falling back to timer2 PWM if the requested pin is not HWPWM capable or if the specified HWPWM channel is already in use. This is all now handled automatically within the firmware and no longer need to be pre-defined in board.txt.

PWM and Servo automatic assignments can be seen in M122 P200 output.

Edited 1 time(s). Last edit at 09/25/2019 08:38AM by sdavi.

sdavi-

that sounds GREAT! I can only imagine the work that went into making it work.

speaking for myself, I am still trying to figure out what the compelling reasons, features and benefits might be to upgrading to RRF3?

i see all the 'whats new' type discussions and how-to and the like, and the mostly deal with what you have to DO to upgrade but I have not seen much on WHY one might want to upgrade from RRF2 to RRF3?

I have looked a bit on here and on the Duet forums, but I don't see much. like this - [duet3d.dozuki.com]

what benefits on LPC might we see once we go through the upgrade process?

sinneD

RRF3 is still in beta, so for the LPC port, mostly aimed at those who want to be on the bleeding edge or help out testing other boards. I think most of the work on the official RRF3 so far has gone into supporting the new duet3 so not much in the way of new features that would be available on the LPC except the new configuration options. If the current version is working, and working well, then probably not much incentive to upgrade just yet. I haven't tested AUX serial in non-paneldue mode so if you rely on that may be best to wait until it has been tested/confirmed working.

I only have an old Azteeg X5 mini which i've just put into an old Up! Mini (so i've been testing printing on that), and a smoothieboard which is on my CNC (although i haven't tested RRF3 on this yet). So any feedback on other boards is welcomed, especially with the new labels etc.

Overall, I think configuration for the LPC is a lot simpler now thanks to RRF3, should be easier for new users in getting started. Hopefully the new configurator for LPC will also generate working config and board.txt with little effort.

On the LPC side of the port mostly under-the-hood type of changes - there are some memory savings, and ADC readings appear to be a little bit more stable now. PWM interrupts are now higher priority than the step int - I think this should help those boards that had heaters on non-HW PWM pins and were previously seeing temp fluctuations that only occurred during certain parts of a print.

I've built the latest version of RRF3.

I am working on adding an entry for the SKR 1.4 in the boards section. I have added the pins as appropriate.

I am defining the board using lpc.board = biquskr_1.4 in the boards.txt file.
How do I know that this has been recognised by the firmware?
There doesn't seem to be an entry in M122 to reflect the selected board (as it would show which duet board RRF is running on).
Is there any other way I can do this?

---

Based in Darlington, North East

Can we just use the duet version of DWC for this?

Edited 1 time(s). Last edit at 01/09/2020 03:25PM by jay_s.

---

Based in Darlington, North East

Quote
jay_s
I've built the latest version of RRF3.

I am working on adding an entry for the SKR 1.4 in the boards section. I have added the pins as appropriate.

I am defining the board using lpc.board = biquskr_1.4 in the boards.txt file.
How do I know that this has been recognised by the firmware?
There doesn't seem to be an entry in M122 to reflect the selected board (as it would show which duet board RRF is running on).
Is there any other way I can do this?

All the board.txt settings are shown in M122 P200, however I do notice just now that it doesn't change the lpc.board string if it can't find it in the boards array and fails to load the pin table - on error it should set the string to "Generic" as that is what pin table is used by default. I'll fix that for next commit. It does print a message to USB if string doesn't match if you connect early enough. I included defaults for the stepper en/step/dir for known boards so they don't need to be in the board.txt unless you wish to override them, so if they are not in board.txt and they show up in M122 P200 then it has loaded the board settings and corresponding pin table too.

Quote
jay_s
Can we just use the duet version of DWC for this?

Yep that will work as well. The only difference between the version I provide and the official one is that it detects the LPC board and when you upload firmware.bin it will automatically prompts to install it as it does on the Duet, and it also recognises when you edit board.txt and prompts if you want to reset like it does when editing config.g. The changes are only for user convenience. There is a DWC2.04 version for LPC in the 2.05 release page. Looks like i forgot to push to the changes for DWC to github so I'll do that soon too.

Edited 1 time(s). Last edit at 01/09/2020 05:39PM by sdavi.

I've just uploaded those changes to github, it now sets the lpc.board string to "generic" if it fails to find the board name in the array. I've also added that lpc board name string to M122 as you suggested as well.

That's great thank you.
I'll test my addition of the SKR 1.4 tonight.

If it work and I push it to github, will you sort out updating the LPCConfigurator? or is that a separate repo I can commit to?

Edited 1 time(s). Last edit at 01/10/2020 03:14AM by jay_s.

---

Based in Darlington, North East

Quote
jay_s
That's great thank you.
I'll test my addition of the SKR 1.4 tonight.

If it work and I push it to github, will you sort out updating the LPCConfigurator? or is that a separate repo I can commit to?

I only did the LPC configurator so it would be easier to give the betas a try at the time - there was no interest there so I abandoned it. Some configuration options in RRF3 I think have changed since then, so best to use the official RRF configurator and adapt the config.g as necessary.

Do you have a full list of custom gcode commands which have been added?

---

Based in Darlington, North East

Quote
jay_s
Do you have a full list of custom gcode commands which have been added?

The only custom gcode in the LPC port is the extra diagnostic (P200) on M122.

Sdavi

Is it possible to increase the scope of whats written to the config-override file?
I'm thinking more for users who don't have network access and are instead using pronterface to control their machine.
It would allow a user to modify any settings and get them stored, rather than making adjustments and having to note them down to update the config.g file when removing the sd card.

---

Based in Darlington, North East

Quote
jay_s
Sdavi

Is it possible to increase the scope of whats written to the config-override file?
I'm thinking more for users who don't have network access and are instead using pronterface to control their machine.
It would allow a user to modify any settings and get them stored, rather than making adjustments and having to note them down to update the config.g file when removing the sd card.

I've never used it nor looked at that part of the code. I like to keep the code as close as possible to RRF to minimise conflicts when merging from the official repo. Config.g isn't that big and I thought pronterface etc you could upload files (slowly) with M28 to the sdcard?

Hi,
I've been working to add support for TMC22XX UART based devices for the LPC port. I've currently got this working in my own fork for TMC2208 devices. So far it seems to work reasonably well. If you are interested in taking a look at what I've done my fork (and branch with this code in it is here):
[github.com]
The build system changes are here:
[github.com]
I've tried to keep things as simple as possible (to make tracking upstream changes easy), but there are almost certainly better/different ways to do some of this. I'm still testing things and work on this, but thought you might find it of interest.


This is a brief description of how things work and some current issues/concerns (taken from the git commit log):

Add LPC support for TMC22XX drivers

This adds support for TMC22XX drivers when using LPC based systems. It
uses the LPC Repetitive Interrupt Timer (RIT) to drive a custom software
UART implemetation. This allows the use of standard GPIO pins to talk to
UART based TMC devices. A single pin is used per device and the UART
operates in half duplex mode. To minimise system impact the UART
operates at a slow speed (9600 baud) and uses a single interrupt per
bit. When the UART is not operating the timer is disabled. The interrupt
handler takes approximately 1uS to execute on an LPC1768 (plus standard
interrupt overhead).

Potential issues
When enabled all active drivers must be TMC22XX devices.

The software UART is sensitive to timing issues. If other parts of the
system delay the RIT interrupt handler then errors will occur. To
improve detection of these errors full CRC checking of responses has
been enabled. Currently no errors are seen when the system is idle, but
during test print jobs an error rate of 0.5% is seen. If there is an
error the operation will be retried. Currently RepRap
firmware polls the drivers constantly to obtain status information. So
far when testing no error has created a false status report. But this is
possible if errors are not detected by the CRC code. It may make sense to change
things so that this polling is optional (can probably be done using the
current M569 R option), the UART interface would then in effect only be
used for configuration.

@sdavi

Ah, ok. Didn't realise about the M28 thing.
I will test it tonight.

And I understand about the not wanting to deviate too much from the RRF codebase.
Do you want the new board commits against the 3 or 3.01 branch?

@gloomyandy

I will try this out tonight and feedback how I get on.
Would there be any loss of functionality if the UART was only used for configuration? I assume sensorless homing couldn't be used on the 2209's but I don't see that as being a big loss.

---

Based in Darlington, North East

@jay_s The main thing you will lose is the monitoring of the drivers (for over temps etc.), which is not a massive loss. I'd like to make it configurable if I can, so it would still be available for debugging etc. I think that sensorless homing would still work as that is triggered by a hardware event and it should then be able to use the UART connection "on demand" to check status. But I've not really looked into any of that as I don't have any TMC2209s. If you do decide to try it out you will need to add some additional configuration to the board.txt file to provide the pins used for the UART connections.This is what I'm currently using for a SKR V1.4 board.: [github.com]

@gloomyandy
Makes sense to make it user configurable.
I've added the SKR 1.4 to what would be this file [github.com] so I odn't have much in my boards.txt
I'll push my changes through to sdavi tonight if I can.

Is your build based on RRF3 or RRF3.01? RRF3.01 is the branch now being developed by dc42, so wouldn't expect any changes in the v3 branch

---

Based in Darlington, North East

My code was forked from sdavi around Xmas so whatever the state of things was then. I see that sdavi is making some changes at the moment so I'm not sure how stable that code is. I'll rebase things at some point.

Well the new branch is very exciting as it introduces conditional gcode.
See here [duet3d.dozuki.com]

---

Based in Darlington, North East

Yes it looks interesting, will it all fit on an LPC176X device though?

Only one way to find out.
sdavi has been building the new branch and hasn't reported any problems yet.

---

Based in Darlington, North East

Yep, the 3.01 branch is where the dev work is going on at the moment.

David has kindly merged in some of LPC RRF code into RRF, this makes keeping the LPC port easier manage as it hopefully means less conflicts when merging in the changes from the official RRF repository. As such, the LPC 3.01 branch is now based on a fresh checkout of RRF 3.01 and the LPC directory and other LPC specific files then added to that. Currently you'll need latest LPCCore:v3-dev, RRFLibraries:dev-lpc and RRF:3.01-dev-lpc.

David has done a great job keeping the memory usage down after needing to switch to newlib from newlib-nano. This means that the LPC port continues to work with networking/wifi in 3.01:

• Wifi - I've finally taken some time to look at the wifi buffers today and testing different buffer sizes and resulting speeds (which is always a fun balancing act). In my test config with a 33M gcode file:
  
  • 1K SDCard filewrite buffer:
    
    • 2x2K networking buffers leaves ~0.6K memory and upload speed of ~228K/s.
    • 2x1K networking buffers leaves ~2.6K memory and upload speed of ~210K/s.
    • 2x0.5K networking buffers leaves ~3.6K memory and upload speed ~190K/s.
  • 2K SDCard filewrite buffer:
    
    • 2x1K networking buffers leaves ~1.6K memory and upload speed of ~240K/s.
    • 2x0.5K networking buffers leaves ~2.6K memory and upload speed of ~230K/s
  • 3K SDCard filewrite buffer:
    
    • 2x1K networking buffers leaves ~0.6K memory with upload speeds of ~252K/s
    • 2x0.5K networking buffers leaves ~1.6K memory with upload speeds of ~240K/s
  • 0.5K SDCard filewrite buffer:
    
    • 2x0.5K networking buffers leaves ~4K memory and upload speed of ~128K/s
• Ethernet - The ethernet version is running with about 2.6K free and just yesterday was updated for 3.01.

Looks like the 2K sdcard filewrite buffers are the best trade off in terms of memory and speed. I think the 0.5K network buffers is a good pick leaving 2.6K of free memory.

I have only had 3.01 running on my mbed dev board so I have not yet tested any movements or heaters or anything yet. It will probably be some time before I can test it so feedback from anyone that builds and runs it would be appreciated.

--

I've also been looking into the ADC since some users here are also seeing these random very short large spikes on an otherwise clean signal so I've added in an ADC pre-filter before it goes to RRF. I've used one of the strategies from smoothie code, where the last 8 samples are kept, sorted and the middle values averaged. The ADC is still configured to use Burst mode as previously, but when the prefilter is running there will be an extra interrupt occurring after each scan of the active channels to fill up the samples array. The aim is to (hopefully) remove (or at least reduce) the large spikes before they are sent to RRF for processing (assuming they don't persist for several samples).

The prefilter can be turned on by setting lpc.adcEnablePreFilter to true in board.txt as of 3.01

@gloomyandy great work getting the TMC22xx UART implemented.

@sdavi Thanks for the update. So I guess it makes sense to switch testing etc. over to the 3.01 branch? If so I'll try and rebase my branch to that as soon as I can. I'm about to start testing heaters etc. so I don't think it makes sense to continue with the older branch.

In terms of memory I'm curious about the free memory figures. Do dynamic allocations use both LPC main memory and the AHB banks? Is there any scope to make more use of the AHB memory?

@gloomyandy
I've manually merged your code into my v3.01 branch if you want to take a look.
Just about to add my code to include the SKR 1.4 in the boards section

---

Based in Darlington, North East

Quote
gloomyandy
@sdavi Thanks for the update. So I guess it makes sense to switch testing etc. over to the 3.01 branch? If so I'll try and rebase my branch to that as soon as I can. I'm about to start testing heaters etc. so I don't think it makes sense to continue with the older branch.

In terms of memory I'm curious about the free memory figures. Do dynamic allocations use both LPC main memory and the AHB banks? Is there any scope to make more use of the AHB memory?

Official RRF 3.01 is already in beta1. So by the time it's ready for RC or release hopefully the LPC 3.01 version will be tested enough for a binary release, I don't plan on a 3.0 release.

Yes, both main and AHB are used for dynamic allocations when using new and in any FreeRTOS dynamic allocations, but not malloc (it's hardly used in the port so never bothered). I'm using FreeRTOS Heap5 which allows spanning of multiple non-contiguous memory locations, and I modified the 'new' and 'delete' operators to use the pvPortMalloc and vPortFree instead of malloc and free. Most of the statics are placed into the AHB ram by the linker script. The only thing it doesn't report is how much is free in each memory block which I would like to add in at some point.

I'm getting a build error on the latest RRFlibraries

RRFLibraries/src/Math/Deviation.cpp:11:1: error: declaration of 'Deviation:eviation()' has a different exception specifier
 Deviation:eviation() : mean(0.0), deviationFromMean(0.0)
 ^~~~~~~~~
In file included from RRFLibraries/src/Math/Deviation.cpp:8:
RRFLibraries/src/Math/Deviation.h:17:2: note: from previous declaration 'Deviation:eviation() noexcept'
  Deviation() noexcept;
  ^~~~~~~~~
RRFLibraries/src/Math/Deviation.cpp:15:6: error: declaration of 'void Deviation:et(float, float, size_t)' has a different exception specifier
 void Deviation:et(float sumOfSquares, float sum, size_t numPoints)
      ^~~~~~~~~
In file included from RRFLibraries/src/Math/Deviation.cpp:8:
RRFLibraries/src/Math/Deviation.h:19:7: note: from previous declaration 'void Deviation:et(float, float, size_t) noexcept'
  void Set(float sumOfSquares, float sum, size_t numPoints) noexcept;
       ^~~

Looks like an error with the code that was committed from the official branch.
Any ideas?

This is a clean build from sdavi's branches without any changes

---

Based in Darlington, North East

Yeah oops, I forgot to commit that fix yesterday, it needed the noexcepts in the cpp file otherwise it doesn't compile I just pushed it to GitHub just now.

I've now got the latest 3.01 branch built with @gloomyandys code included.
I'll test the build when I get home and make sure it loads and I can adjust the drivers etc.
Would you be happy for a pull request to then be created for andys code and my addition of the SKR 1.4?

---

Based in Darlington, North East

I'd prefer to hold off merging my code for a few days. I'd really like to get in place the ability to turn off the polling of the drivers and to check it out with the 3.01 code a little first.