RepRapFirmware 3.0 port for LPC1768/9 based boards

One problem I hit earlier was that pins that that are not in the pin table (perhaps because they do not have an explicit name, like say the SPI pins that are in the screen header, or the UART pins in the various headers, or the motor driver pins) can not be easily accessed (including by their pin number), say if you want to use them for some other purpose. With things like Marlin it is common to re-purpose these pins for other things (like extra sensors, driving LEDs etc.), but I'm not sure if that is possible with RRF (so for instance if you are not using say the UART, can the pins be used for other things?).

Was that on the 1.3 or 1.4?
There's a couple of the pins I've missed on the 1.4 (namely the pwrdet, neopixel and probe).

---

Based in Darlington, North East

Bear in mind that in RRF3 on Duets, if a pin name starts with a number then that number is the expansion board number. So I suggest "p1.27" rather than just "1.27".

---

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].

Hi All!

I apologize for my English.

My question is: is it planned to support 2130 drivers?

Best regards, Alex

Quote
gloomyandy
I have just updated my build (that does have support for TMC22XX devices in UART mode) and if you would like to try it you can grab the binary here:
[github.com]
Note that this is built for WiFi not ethernet.

I just tested on an SKR 1.4 board with 2208 XYZ and 2209 E drivers.
UART OK
Set microstepping OK
Set current OK
Set interpolation OK
Set stealthchop mode - Not working.

Edited 1 time(s). Last edit at 02/11/2020 06:01AM by SilentStorm.

What are you doing to set stealthchop and how are you determining what mode they are in? I have TMC2208s and they seem to be working fine in stealthchop mode. I'm pretty sure they are in stealthchop by default. They will switch to spreadcycle when your speed exceeds the threshold set with M569 V, you may want to check the value set for this as the default setting is a pretty slow speed and so the motors will often be in spreadcycle. See the documentation for M569 [duet3d.dozuki.com] for how to check what speed it will switch at.#

@jay_s firstly things may have changed since I last tried this, but last time I looked none of the pins for the stepper drivers are in the pin table (because they are specified in a "special" array of pins), similarly I don't think the pins used for the external SPI or the UART pins are in pin map (because normally they will be referenced as a UART or SPI device implicitly), but if you want to use then for some other purpose then it is not possible to do so. But as I said this needs to be checked as it has been a while!

Quote
gloomyandy
What are you doing to set stealthchop and how are you determining what mode they are in?

The same printer running Marlin 2.0 runs completely silently. Perhaps the default settings in Marlin are configured more correctly. Can you compare the 2208 default settings from Marlin with the settings in RepRap?

By default Marlin has the threshold disabled, RRF has a very low setting for it and so will switch to spreadcycle at a relatively low speed (which is safer as you are less likely to lose steps but produces more noise). But as I mentioned above you can easily tune that setting by using M569, why not try adjusting the value and see how things change?

Lower settings increase the speed at which the driver switches from stealthchop to spreadcycle. The default setting is 4000 which will typically switch at a fairly low speed, but the the actual speed depends upon how your machine is configured. As I said above if you read the documentation for M569 it tells you how you can use it to determine what speed your current setting will switch at. So M569 P0 will typically tell you what speed your X driver will switch at. You can then adjust the setting using M569 P0 Vxxx where xxx is your new threshold setting and then run M569 again to see the new switch speed. You may find that values like 100 or even lower work better for you, but as always it very much depends on your printer hardware.

Quote
gloomyandy
@jay_s firstly things may have changed since I last tried this, but last time I looked none of the pins for the stepper drivers are in the pin table (because they are specified in a "special" array of pins), similarly I don't think the pins used for the external SPI or the UART pins are in pin map (because normally they will be referenced as a UART or SPI device implicitly), but if you want to use then for some other purpose then it is not possible to do so. But as I said this needs to be checked as it has been a while!

Yes this was done on purpose for those using the pre-compiled binary, to avoid someone making a typo etc leading to errors/weird behaviour on the steppers, UART and SPI (which could have a SDCard connected etc). If there is no display/sdcard connected then there is already a number of spare pins that are already usable.

But yes it is possible to use nearly any pin you want by compiling your own firmware.bin. UART is assumed to be used, but can be disabled by not defining SERIAL_AUX_DEVICE in Pins_LPC.h. Any pins you want to make available for gcode need to be in the pintable. SPP isn't initialised until it is first used so if using those pins then you just need to ensure you don't enable anything that uses it. The generic board has most pins available already (i think even including UART), you only need to uncomment a few lines if you really want access to the SPI pins.

Edited 2 time(s). Last edit at 02/11/2020 09:41PM by sdavi.

Hi @sdavi, I've just noticed that some of your RRF repos are currently marked as archived. I hope that doesn't mean you no longer plan to update them as that would be a great pity.

Quote
sdavi

Yes this was done on purpose for those using the pre-compiled binary, to avoid someone making a typo etc leading to errors/weird behaviour on the steppers, UART and SPI (which could have a SDCard connected etc). If there is no display/sdcard connected then there is already a number of spare pins that are already usable.

But yes it is possible to use nearly any pin you want by compiling your own firmware.bin. UART is assumed to be used, but can be disabled by not defining SERIAL_AUX_DEVICE in Pins_LPC.h. Any pins you want to make available for gcode need to be in the pintable. SPP isn't initialised until it is first used so if using those pins then you just need to ensure you don't enable anything that uses it. The generic board has most pins available already (i think even including UART), you only need to uncomment a few lines if you really want access to the SPI pins.

I think that actually makes a lot of sense as it avoids folks using the pre-compiled binaries from running into problems that they may not understand. In anyone really wants to hack on things there is always the option of compiling from source or perhaps falling back tot the generic board type. Seems like a reasonable solution to me.

Quote
gloomyandy
Hi @sdavi, I've just noticed that some of your RRF repos are currently marked as archived. I hope that doesn't mean you no longer plan to update them as that would be a great pity.

They have been archived as I don't plan to do any further updates at this time. I've left everything there on GitHub so others can fork it and can merge in changes from the official RRF repository to stay up-to-date.

Edited 1 time(s). Last edit at 02/13/2020 11:43PM by sdavi.

Folks, sdavi has lots of stuff to do at the moment so myself and @jay_s are going to try and keep things ticking over until he gets back. As part of this I have updated the source in my fork to V3.01-RC2. In addition to the RC2 updates this binary includes code to support TMC22XX devices via UART, the ESP8266 WiFi module, pre-filtering for the ADC and the capability to attach a PanelDue display. Some of these features may require extra settings in boards.txt. I've also included fixes for a couple of problems the most important of which was a race condition when using software PWM for the heaters. Please remember that this code is experimental and that you use it at your own risk. Please take particular care when running heaters. The binary can be found here:
[github.com]

Source code is here:
[github.com]
[github.com]
[github.com]

I've run a few basic tests on the binary and so far so good! I'll be testing it more over the next few days.
If other binaries are of interest please let us know.

Quote
sdavi

Quote
gloomyandy
Hi @sdavi, I've just noticed that some of your RRF repos are currently marked as archived. I hope that doesn't mean you no longer plan to update them as that would be a great pity.

They have been archived as I don't plan to do any further updates at this time. I've left everything there on GitHub so others can fork it and can merge in changes from the official RRF repository to stay up-to-date.

Thanks for your great work !

---

"A comical prototype doesn't mean a dumb idea is possible" (Thunderf00t)

@dc42 just published his future plans for RRF 3.X over on the Duet3d forum, may be of interest to some here: [forum.duet3d.com]

No idea how some of the new features (variables?) will impact memory usage on the LPC devices, will be interesting to see!

@gloomyandy

Maybe we would be able to leverage a connection to an SBC if and when that's implemented on the Duet 2?

I have some issues with my hot end/extruder on my test machine but once thats fixed I intend to start playing with conditional gcode.

---

Based in Darlington, North East

Quote
jay_s
Maybe we would be able to leverage a connection to an SBC if and when that's implemented on the Duet 2?

In an early version of RRF3.0 I had this compiling (but not tested with a SBC) on the LPC back when the default RX and TX buffer size was I think were only about 4K each. I didn't continue with it when the default buffer size was increased to 8K each for RX and TX which did not fit on the LPC (back then there was only about 15K free when networking wasn't compiled in, and is likely even less now in 3.01). I don't recall DSF having a config variable for the SPI buffer transfer size like it does with frequency, so the DSF code would need modifying to use the same smaller buffer size as on the LPC so they both remain in sync (assuming there are no other issues with running at the smaller buffer size).

@sdavi That's interesting I've not really paid much attention to the SBC/DSF side of RRF 3.0 (I assuming it was simply not possible with the LPC version). Having now had a quick glance at it I wonder if it may be possible. My understanding is that certain functions get migrated to the rPi from the RRF control board. Does this migration free up any RAM on the LPC I wonder (things like the network buffers if using WiFi or possibly the SD card buffers?). Just random thoughts really. Is there any sort of documentation of how all of this hangs together? 16Kb for buffers is a big ask for an LPC though!

On a related note, do you have a good way to take a look at what the memory usage of an LPC based port is? I guess the map file contains information on the statically allocated parts, but it would be nice to have an overall picture of what the RAM is being used for.

Quote
gloomyandy
@sdavi That's interesting I've not really paid much attention to the SBC/DSF side of RRF 3.0 (I assuming it was simply not possible with the LPC version). Having now had a quick glance at it I wonder if it may be possible. My understanding is that certain functions get migrated to the rPi from the RRF control board. Does this migration free up any RAM on the LPC I wonder (things like the network buffers if using WiFi or possibly the SD card buffers?). Just random thoughts really. Is there any sort of documentation of how all of this hangs together? 16Kb for buffers is a big ask for an LPC though!

On a related note, do you have a good way to take a look at what the memory usage of an LPC based port is? I guess the map file contains information on the statically allocated parts, but it would be nice to have an overall picture of what the RAM is being used for.

Yeah I had it compiling and running on the LPC before (I just can't remember how much free memory there was) and was about to test it until I found that DSF didn't run on the Raspberry Pi Zero W i had laying around and eventually lost interest in it and did the esp wifi instead. It didn't have all the networking parts and their larger buffers compiled in which saved a lot of memory. I.e. the httpresponders i think are around 2K each and there are 2 configured, plus the memory for the network task, network buffer, ethernet build (emac buffers, +tcp buffers and tasks....) etc. Some of the old ifdefs i was using for board config etc is in the old v3 branch, although I never checked in the changes in the /Linux/ directory (but they were very similar to what was required for the ESP wifi code).

M122 P105 will print out some object sizes that might be helpful. DC42 also had a spreadsheet with memory usage back in early V2: [github.com] that might still be useful for a general overview.

I did a bit of testing yesterday, and the 3.01-RC3 LPC NoNetworking standard build leaves (on my setup) 15,960 bytes of never used RAM. Nowhere near enough for the default config of SBC build, but after slashing some buffers (i.e. only 2K SPI buffers instead of 8K, 1/2 code buffer etc etc) a cut-down version of the SBC code can squash into ~9.5K leaving 6,304 bytes of free RAM. I did still have the SD support compiled in (to load the board config) and removing that could save a bit more space. How well/if it runs with the reduced buffers I don't know, but it may be possible to run the SBC version with the LPC (with the appropriate edits to DSF).

@sdavi, that's interesting, but a little worrying that we need to go so much lower on the buffer sizes, to get things to fit. I wonder if it will even run with buffers that are so much smaller? I had a quick look at the DSF code and changing the buffer size looked reasonably simple (as DC42 already changes it from the default 4K). In your build do you have code that actually handles the Linux SPI interface on the LPC, or would that need doing to be able to test things? I wonder how much space building without the SD card would save (I thinksome of the V3 duet cards operate without an SD card)? Though notbeing able to load the board config would be a pain.

Folks,
I've merged the latest V3.01-RC3 changes into my fork (along with a few fixes to allow building on Linux and to fix a typo from a previous merge), but I'm away at the moment so can only build things on Linux and can't test the build at all. If anyone is really keen to try RC3 I can supply my binary (or you can try building it), or if you don't mind waiting I'll test things and upload a "release" when I get back at the end of the week.
The merged code is here:
[github.com]
[github.com]
[github.com]

Quote
gloomyandy
@sdavi, that's interesting, but a little worrying that we need to go so much lower on the buffer sizes, to get things to fit. I wonder if it will even run with buffers that are so much smaller? I had a quick look at the DSF code and changing the buffer size looked reasonably simple (as DC42 already changes it from the default 4K). In your build do you have code that actually handles the Linux SPI interface on the LPC, or would that need doing to be able to test things? I wonder how much space building without the SD card would save (I thinksome of the V3 duet cards operate without an SD card)? Though notbeing able to load the board config would be a pain.

Yeah I was just curious to see what was required to get it to fit and start up without running out of memory (and leave enough memory for future updates). I don't know much about it, so I don't know what the minimum buffer sizes etc that are required - it may be that there is just not enough memory available for it to run. I've just copied the spi code from the esp wifi networking with a few small changes so it would compile. Since I don't have a SBC connected, I have no way I knowing if it works or not.

Quote
gloomyandy
@sdavi, that's interesting, but a little worrying that we need to go so much lower on the buffer sizes, to get things to fit. I wonder if it will even run with buffers that are so much smaller? I had a quick look at the DSF code and changing the buffer size looked reasonably simple (as DC42 already changes it from the default 4K). In your build do you have code that actually handles the Linux SPI interface on the LPC, or would that need doing to be able to test things? I wonder how much space building without the SD card would save (I thinksome of the V3 duet cards operate without an SD card)? Though notbeing able to load the board config would be a pain.

The SBC hosts a virtual SD card which displays on DWC exactly the same way as an onboard one does. Therefore, we should have no issue loading the board.txt file.
The virtual SD card also contains the config.g file etc.

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

---

Based in Darlington, North East

The problem is that the SBC connection is probably established after the board.txt file has been read! In fact there is a good chance that the link may need data that is in the board.txt file to actually configure it (like what pins to use for the handshake etc.). We can probably hard code the link details but it kind of defeats the purpose of having the board.txt file in the first place.

Ah, that's very true. Never thought of that.
I think it would be acceptable to hardcode the pins required for the added gains you'd get.
And if someone needs to change the pins, they can build it themselves

---

Based in Darlington, North East

It should be possible to still keep board.txt (on the internal SDCard), just update the board config loader to use FatFS to load the file rather than through the RRF MassStorage class.

I was playing around with the SBC version again today, and disabling MassStorage saves a nice chunk of memory (around 6K of RAM). Currently, I have it running with MassStorage disabled, 4K SPI buffers, max code len of 104 and 2K gcode cache and there is a good 8,264 bytes of free RAM. With the amount of free ram it's probably not necessary to reduce the codelen and gcode cache.

So I hooked up a pi3 and so far its working with a recompiled DuetControlServer. I was able to connect to DWC running on the pi, and run my the gcode test file that i normally used for debugging. It's been running for a couple of hours now without any errors. (only on my mbed board and not hooked up to a printer or anything)

Edited 1 time(s). Last edit at 03/02/2020 04:12AM by sdavi.

I have a spare SBC of you want me to test anything

---

Based in Darlington, North East

@sdavi That sounds pretty good! I'm looking forward to giving it a go with the Pi I have already got attached to my printer. How easy was it to create a cable to hook the two boards together? Is the connection similar to the WiFi board (SPI plus some handshake lines)? I've not really looked at how things get split between the two boards, so I'm not 100% sure what the advantages are of that system (obviously you get a better web server), are things like macros executed on the SBC or on the control board, or is there only a subset of the gcode sent to the control board?