RepRapFirmware 3.0 port for LPC1768/9 based boards

Quote
gloomyandy
@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?

Connection is same as Wifi except it only requires 1 GPIO handshake pin. I Connected SSP0 to SPI0 on the pi, SSEL0 to SPI0_CE0 on the pi, the handshake pin to GPIO25 on the pi and GNDs. I didn't make a cable, just using prototyping wires.

I haven't used it much, just wanted to see if it would work. As you'd expect the upload speeds are a lot faster. Although I will continue to use the esp wifi on my cnc.

That sounds pretty simple. I was a bit concerned because the Duet 3 seems to use a fairly substantial ribbon cable, so wasn't sure if it needed extra signals etc. What speed are you running the SPI connection at? I assume it is slower than the Dueat 3 uses? Are you seeing and SPI errors?

If you can make your changes available at some point, I'll merge them into my build and give them a try when I get home.

If you look at the wiring diagram, 7 of the connections are for providing power to the raspberry pi.
Theres only 5 connections that are required for the SPI connection.

The pi does a lot of pre-parsing of the code from what I understand

---

Based in Darlington, North East

Quote
gloomyandy
That sounds pretty simple. I was a bit concerned because the Duet 3 seems to use a fairly substantial ribbon cable, so wasn't sure if it needed extra signals etc. What speed are you running the SPI connection at? I assume it is slower than the Dueat 3 uses? Are you seeing and SPI errors?

If you can make your changes available at some point, I'll merge them into my build and give them a try when I get home.

I've uploaded the changes, but it's pretty rough, no loading of board.txt and the handshake pin was hardcoded etc etc.

I think i was only testing at about 1MHz for the spi speed, ran for hours without any errors. Didn't try anything faster. I do run the WIFI at 6MHz (although its not connected by long wires) - when running in slave mode 1/12th of SSP pclk is the max speed, but with the wifi (on LPC1768) 7MHz and 8MHz was causing data errors but 6MHz was good.

So the Duet provides power to the pi? I wonder how good an idea that is? Is it normal in this setup just to turn the power off on the printer, which presumably turns off the power to the pi? In my experience of the pi (with older versions of the pi), this can easily result in the pi's SD card becoming corrupt. I wonder if this is still a problem with this setup?

You get a choice about how you want to power the pi using some onboard headers. I believe the duet can supply up to 3A at 5V which is more than enough for the pi and a couple of other things.
This does give the opportunity to run the pi off its own supply and then turn off the duet when not needed.

The recommended version of the pi to use is 3B+ or a 4. With the 3B+ you can boot from USB, which removes the corruption issue. The pi can't do this yet but you can move the root partition off to an SSD.

I run my duet 3 off the pi with the OS ran from a 48Gb SSD. I use a relay to turn it on and off and haven't had any issues with SD corruption yet and hopefully won't as it only runs the boot partition.

---

Based in Darlington, North East

Hi @sdavi, thanks for uploading the files. I'm hoping to make a start on trying this tomorrow at some point. But I'll need to get my pi running the Duet software and hook things up. Did you have to make any changes to the pi software side of things (for clock speed or buffer size etc?). Did you include any resistors in the connections between the pi and the LPC (like the ones that are present between the WifI module and the LPC)? I had a quick look around but couldn't find the schematics for the duet 3 boards to see if they have anything built in on those I/O lines.

Duet 3 schematics are here [github.com]

---

Based in Darlington, North East

Ah thanks for that @jay_s I obviously did not look hard enough! Looking at the schematic it seems that they do indeed have resistors on the SPI lines 100 ohms on mosi/miso/cs and 470ohms on the clock and data ready.

Quote
gloomyandy
Hi @sdavi, thanks for uploading the files. I'm hoping to make a start on trying this tomorrow at some point. But I'll need to get my pi running the Duet software and hook things up. Did you have to make any changes to the pi software side of things (for clock speed or buffer size etc?). Did you include any resistors in the connections between the pi and the LPC (like the ones that are present between the WifI module and the LPC)? I had a quick look around but couldn't find the schematics for the duet 3 boards to see if they have anything built in on those I/O lines.

There was a few changes needed in DSF. Changes in buffer size or gcode line length on the LPC need to be replicated in DSF (DuetControlServer/SPI/Communication/Consts.cs). SPI Mode in LinuxDevices/SpiDevice.cs. DSF was also expecting the CPU temps and voltage-in values which aren't sent on the LPC and I just commented out those lines, but I can't remember which file that was in. The clock speed is settable in the DSF config file.

@sdavi thanks for that, I'll take a look at the DSF source and make the same changes.

I noticed that you have been looking at possible problems with the software PWM code. I've also been seeing issues with it (leading to heaters being set to either full on or off for some time), this seemed to happen a lot when I attached a panel due to my printer. I eventually tracked it down to a sort of race condition. Basically if the panel due UART interrupt happened between calculating a delta for the us timer and actually setting it the timer can have ticked and so the new time is now in the past (which then means it will not fire until it has gone through a 32 bit wrap around). This could happen either when setting a new time, or when setting the timer for the new "head of queue" in the timer interrupt handler (because the UART handler runs at a higher priority). I added some code to the setting logic to detect this and adjust the time to always be (just) in the future in this fix:[github.com] there are probably better ways to fix it but I've not had any issues since adding this and I saw the problem a lot with the old code. In my fork I have also switched the us timer code to use the RIT rather than timer 3 allowing the TMC22xx UART code to use timer 3 and so allow both that code and the A/D smoothing code to be used at the same time. You can see those changes here: [github.com]

I will probably follow your model and merge these changes into SoftwarePWMTimer.

Oh and my fork also contains changes to the build to allow the LPC176X UART to not be used in conjunction with the WiFi module, this allows the use of both WiFi and panel due.

I hope these changes make sense.

@sdavi Ah I see you had already added a fix for the time being in the past! Just merging your changes at the moment and actually spent some time reading the code!

Hi @sdavi I now have my rPi and SKR V1.4 board talking to each other (at the default 2MHz SPI speed). Which is pretty cool. Great work (again!). Hopefully tomorrow I can try a few more things out and perhaps even hook it up to my printer control board and test things there. I'm not sure that I have a very consistent rPi setup at the moment as I'm using the released rPi duet3 boot disk but DCS built from source, I probably need to sort that out before I go any further!

Quote
gloomyandy
Hi @sdavi I now have my rPi and SKR V1.4 board talking to each other (at the default 2MHz SPI speed). Which is pretty cool. Great work (again!). Hopefully tomorrow I can try a few more things out and perhaps even hook it up to my printer control board and test things there. I'm not sure that I have a very consistent rPi setup at the moment as I'm using the released rPi duet3 boot disk but DCS built from source, I probably need to sort that out before I go any further!

Good to hear you got it going. Yeah, I had some issues compiling parts of DSF so was just using the webserver from apt and the compiled duetcontrolserver for quick testing.

@gloomyandy

Could you fork the DSF repo and commit your changes?
I'd like to look at getting this built and tried out.

---

Based in Darlington, North East

I've modified BoardConfig.cpp to use ff.c directly when loading board.txt which makes it possible to fully initialize things when using the SBC. With this configuration my system has around 6Kb free (this includes the space needed for TMC22XX drivers). I only have this working on my test setup (so not a full printer), but I've been able to run motors, turn on fans and execute test gcode files all with no problems.

@jay_s I'll try and sort out the DSF repo tomorrow at some point.

Sorry but where can I get the latest "solid" firmware.bin to give it a try ?

---

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

@MKSA

Please see here

---

Based in Darlington, North East

@sdavi @gloomyandy

Was this the error you were seeing when trying to build DSF?
How did you get around it?

Middleware/CustomEndpointMiddleware.cs(255,40): error CS0012: The type 'PipeWriter' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.IO.Pipelines, Version=4.0.2.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. [/home/pi/DSF/DuetSoftwareFramework/src/DuetWebServer/DuetWebServer.csproj]

---

Based in Darlington, North East

@jay_s nope I've not seen that error, but I was only building the main DSF server (using the dotnet publish command) and it seemed to build fine.

@MKSA

The ethernet build has just been updated.
If possible, I would suggest using a static IP with M552 rather than setting it to DHCP

---

Based in Darlington, North East

@jay_s if it helps this was the command I used to build the main server:

 dotnet publish -r linux-arm -c Debug -o /opt/dsf/bin DuetControlServer.csproj

Oh and I did this on the rPi not using any sort of remote build setup. I haven't tried building the web server side of things.

I've created a fork with the changes I had to make to get things working, you can find it here: [github.com]

@gloomyandy

Thanks for that. All compiled, built and transferred. How do I know its the LPC version running?

Could you post your board.txt file?

---

Based in Darlington, North East

You can tell that an LPC version is running because it works with an LPC board :-) I should probably change the version number or something, but I don't think we are really at that stage just yet, I'm still exploring what works.

My board.txt file looks like this...

/Config file to define Hardware Pins LPC Boards.
//Note: Each line should be less than 120 characters.
//    : Unwanted options can be commented out or set to NoPin. Lines commented out will get default values
//    : for pins the default is NoPin.
//    : Values for Arrays need to be contained within { and }
//    : Comments can be defined with // or # (comments are not supported inside arrays)
//    : Each config entry must be all on a single line.
lpc.board = biquskr_1.4


8266wifi.EspDataReadyPin = 0.28
8266wifi.LpcTfrReadyPin = 1.30
8266wifi.EspResetPin = 1.31
linux.TfrReadyPin = 0.28
lpc.adcEnablePreFilter =true

Most of that is actually for when I'm running the WiFi version, the only item needed for the SBC is the linux.TfrReadyPin line.

Quote
jay_s
@MKSA

The ethernet build has just been updated.
If possible, I would suggest using a static IP with M552 rather than setting it to DHCP

I tried with RRF 3, same problem. I also connected the printer directly to the router. Same. Even tried DHCP. Same.

With network monitoring in Chrome (or Firefox) I can confirm the loading of the script takes 15 MINUTES (2.2M. It is always

Just in case, I also tried with a different SD card.

May be just my MKS SABASE that is a lemon ???

---

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

@MKSA

I get a connection easily less than 1 minute if not closer to 30 seconds.

I have another MKS board that has a borked network connection. It would probably be possible to connect a wifi module to the board and use that instead.
I wouldn't be sure on which pins to use on EXP1 and EXP2 though. Might be worth looking at if you have a spare wemos D1 or nodeMCU board kicking about.
If you do go that route, if you could let me know pins used etc, I'll add it to the wiki

---

Based in Darlington, North East

@MKSA I also tested RRF 3.01 on an MKS SBASE using Ethernet yesterday, the load of the DWC took 30seconds to a minute for me (though it seemed like an age compared with WiFi or via the SBC). Not sure what is going on with your setup, I wonder if there is something odd going on with the SBase on your network/router (it only runs at 10MBits which is unusual these days).

Quote
jay_s
@MKSA

I get a connection easily less than 1 minute if not closer to 30 seconds.

I have another MKS board that has a borked network connection. It would probably be possible to connect a wifi module to the board and use that instead.
I wouldn't be sure on which pins to use on EXP1 and EXP2 though. Might be worth looking at if you have a spare wemos D1 or nodeMCU board kicking about.
If you do go that route, if you could let me know pins used etc, I'll add it to the wiki

I think the best is to get an other kind of board. The MKS uses 8825 stepper drivers I don't like anyway. This is just an other reason to get rid of it.
It connects at 100Mb/s by the way. I tried auto speed, fixed and no difference. Anyway, at 10Mb/s it would still be OK. Here the download "speed" I get is in the 20Kb/s range !!!

---

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

@MKSA

Any thoughts on what board you are going to go for?

---

Based in Darlington, North East

Quote
jay_s
@MKSA

Any thoughts on what board you are going to go for?

Not really and with what is happening, there could be delays from China ! A Duet may be ?

Note that I am not blocked, I can use my machine, just that now that I "tasted" DWC

---

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