RepRapFirmware 3.0 port for LPC1768/9 based boards
September 25, 2019 07:28AM
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.
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards
September 30, 2019 08:43PM
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
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards
October 01, 2019 01:20AM
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.
Sorry, only registered users may post in this forum.

Click here to login