LPC port of RepRapFirmware

Hi -

sdavi, thanks for this and all your hard work ! small request/suggestions - put a link on the git page to here. it took me a while to find this page. i am trying to config REARM and could use some coaching.

1. can you confirm that the LCD info applies to the usual RRD Full graphic controller? I think so but I am not sure.
//LCD Pins (only ST9720 SPI currently supported)

and that it use the same scheme as the RAMP adapter instructions from here?

[panucattdevices.freshdesk.com]

I get power to the display but no info. i checked the pin assignments on the example rearm config file but no luck as of yet. It looks pretty much like the assignments I had under Marlin and Smoothie.

EDIT: smoothie had some of the pins marked as inverted and/or hi|lo. do we need to do the same here?
EDIT2: I am looking at these pages -
[duet3d.dozuki.com]
[duet3d.dozuki.com]

and have come to the conclusion that beyond the board.txt pins, you have to enable the display and write menus for it.

2. Network options- the ethernet daughterboard is out of stock at panacutt. I am trying to make heads and tails out of the ESP8266 references. Is this an option or wait for the OE hardware?

EDIT 2: I am putting all my notes for setting up my ReARM on my git page. [github.com]

Best Regards,

Dennis

Edited 4 time(s). Last edit at 05/03/2019 12:06AM by sinned.

Quote
sinned
Hi -

sdavi, thanks for this and all your hard work ! small request/suggestions - put a link on the git page to here. it took me a while to find this page. i am trying to config REARM and could use some coaching.

1. can you confirm that the LCD info applies to the usual RRD Full graphic controller? I think so but I am not sure.
//LCD Pins (only ST9720 SPI currently supported)

and that it use the same scheme as the RAMP adapter instructions from here?

[panucattdevices.freshdesk.com]

I get power to the display but no info. i checked the pin assignments on the example rearm config file but no luck as of yet. It looks pretty much like the assignments I had under Marlin and Smoothie.

EDIT: smoothie had some of the pins marked as inverted and/or hi|lo. do we need to do the same here?
EDIT2: I am looking at these pages -
[duet3d.dozuki.com]
[duet3d.dozuki.com]

and have come to the conclusion that beyond the board.txt pins, you have to enable the display and write menus for it.

2. Network options- the ethernet daughterboard is out of stock at panacutt. I am trying to make heads and tails out of the ESP8266 references. Is this an option or wait for the OE hardware?

EDIT 2: I am putting all my notes for setting up my ReARM on my git page. [github.com]

Best Regards,

Dennis

That's a good idea linking to here from github - will add that next update. Great work getting some notes up about the port, if you don't mind I could also provide a link to your notes as well.

1. Looks like you mostly have the LCD working now? I have a RRD Full Graphic working on my Azteeg X5 mini, I configure it with: M918 P1 F1000000. Some people may need set the SPI frequency (i.e. to 1MHz) if the 2MHz default doesn't work. BTW, the beeper currently doesn't work as expected.

2. The LPC port currently only supports the LPC ethernet, which in the case of the ReArm requires the networking module. Connecting a ESP8266 in a similar way to the duet wifi is not something I've looked at - that code isn't compiled (or even ported) so if you were keen you would need to modify the existing RRF code that interfaces to the 8266 so that it can run on the LPC cpu (SPI, spare pins etc). I'm also not sure about the transfer buffer sizes etc it uses so it may also require tweaking to fit into RAM (there would still be restrictions on number of http responders etc due to memory constraints).

thanks sdavi.

Perhaps I got confused by David's posts- I though that he was suggesting using something like the ESP8266 port of the Duet webserver as described here-

"ESP8266 Duet web interface for any board"
[reprap.org]

and here
"DuetWiFi Server"
[github.com]

It seemed like a wi-win since the ESP8266 has goobs of memory compared to the board.

I will see if I can get my hands on the ethernet module in the meantime. Otherwise, I wonder how functional a generic SPI/LAN module might work-
[www.waveshare.com]
[os.mbed.com]

Hoping that dc42 might jump back into the discussion ....

Edited 3 time(s). Last edit at 05/03/2019 11:43AM by sinned.

I am totally out of my element here, but I will try anyhow.... If I understand your correctly. the LPC has the functionality in it. It just needs the hardware... Panacutt is out of the adapters.

Searching for "hanrun hr911105a 17/02" i see that its a ethernet shield... not sure if i trust this page-

NC28J60

its an SPI ethernet shield.

So instead, can we use something like the Waveshare LAN8270 to work as the dongle? If it has to be SPI, then the ENC28J60

Would this work for boards that do not have the expansion card option?

Mapping the pins from this doc (highlights are mine)-

UM10360 - LPC17xx user manual



curiosuly, later in the doc, it references '1758 only'



I get these mappings. I used the LAN8270 for reference, but you get the idea



Edited 1 time(s). Last edit at 05/03/2019 12:52PM by sinned.

Quote
sinned
I am totally out of my element here, but I will try anyhow.... If I understand your correctly. the LPC has the functionality in it. It just needs the hardware... Panacutt is out of the adapters.

So instead, can we use something like the Waveshare LAN8270 to work as the dongle? Would this work for boards that do not have the expansion card option?

mapping the pins from this doc (highlights are mine)-

UM10360 - LPC17xx user manual

LC8Zvhy.png

curiosuly, later in the doc, it references '1758 only'

y5rp7K9.png

I get these mappings.

aiXlqHU.png

I was going to suggest the same thing :-)

Here's a guide to connecting a LAN8720 to an LPC1768 microcontroller. It only requires a small modification of the LAN8720 module.

/Hans

I edited the page a couple of times- i can not tell if the PHY device needs to be fixed or SPI.

that link is interesting. i'd feel better verifying the datasheet- buying from a reputable source or a lot more digging...

the panacutt prodcut page is "https://www.panucatt.com/product_p/lan8720.htm"

so i am hunching that its an 8720 that i need. but i think that my pin mappings are right.

Hanrun hr911105a is just the ethernet connector. There is a controller chip on the module. On the first module you link to (NC28J60) it is an SPI interface. The LAN8720 is serial and, as I can see, it is a serial interface that LPC1768 needs. I ordered a LAN8720. Then we'll see. :-)

Quote
sinned
thanks sdavi.

Perhaps I got confused by David's posts- I though that he was suggesting using something like the ESP8266 port of the Duet webserver as described here-

"ESP8266 Duet web interface for any board"
[reprap.org]

and here
"DuetWiFi Server"
[github.com]

It seemed like a wi-win since the ESP8266 has goobs of memory compared to the board.

I will see if I can get my hands on the ethernet module in the meantime. Otherwise, I wonder how functional a generic SPI/LAN module might work-
[www.waveshare.com]
[os.mbed.com]

Hoping that dc42 might jump back into the discussion ....

Revision 1.19 and later firmware for the Duet WiFi run just a TCP/IP socket server and a DHCP client on the ESP-12S or ESP-07S module (project DuetWiFiSocketServer). The HTTP, FTP and Telnet servers run on the Duet main processor. So the TCP/IP buffers use RAM on the ESP module, but file buffers and buffers for assembling the HTTP messages live in RAM on the main processor. This should still give a RAM saving on the main processor compared to running any TCP/IP over Ethernet stack on the main processor.

One of or goals was to achieve a reasonable speed for uploading files over WiFi to the SD card. There are at least two elements needed to achieve this:

1. A high speed SPI connection between the ESP module and the main processor. We use a dedicated SPI channel with a clock rate of 26.67MHz and DMA to do the communication. The ESP can do higher, but when we tried increasing to the next available speed (40MHz) we got occasional unreported underrun errors in the SPI peripheral on the Duet main processor. Other SPI functions on the Duet share a secondary SPI channel, except for the stepper drivers which have another dedicated channel.

2. A high speed interface to the SD card. All Duets (including the legacy ones) use a 4-bit interface to the SD card, giving a bandwidth of around 20Mbytes/sec. AFAIK, Smoothieboard and its clones all use SPI to communicate with the SD card.

So I think you could implement ESP8266 WiFi on the LPC1768/9 boards fairly easily if there is a free SPI channel that you can dedicate to it, although the file upload speed wouldn't be as good as on a Duet because of the use of SPI to interface to the SD card. If there isn't a free SPI channel, then with a little more work I expect you could use the SharedSPI subsystem instead, and reduce the clock rate to take account of the additional loading on the SPI bus.

The "ESP8266 Duet web interface for any board" project is separate. It runs a web server on the ESP8266 and communicates with the main board over serial/UART. It provided most of the DuetWebControl functions, except for file transfer which is very slow because it is using serial async protocol. If you don't need file transfer then it has the advantage of very little RAM requirement on the main board. Updating DuetWebControl on it is a pain because it means building a new SPIFFS image to upload to the ESP module.

HTH David

Edited 3 time(s). Last edit at 05/03/2019 02:55PM 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].

I was thinking that an ESP8266 might function as a serial-wifi bridge.
Kind of like this- [atadiat.com]
The Simpler method.

Edited 1 time(s). Last edit at 05/04/2019 11:04AM by sinned.

I am happy to report that the menu file from here -

https://github.com/mudcruzr/Duet-Maestro-12864-Menu-Files

work really well. I tweaked them a bit for my setup, but the basic framework is there. 90+% of a functional printer is in the menues.

There are a few things that I am still trying to work through-

1. Octoprint consistently experiences a serial exception. I have looked at the suggested fixes, so far nothing has helped. Hoping that the ethernet daughter board will work and then I wont have to rely on Octoprint.

2. Access to the SD card / Sneakernet. I miss this the most from Marlin 2.0 and smoothie. With raspi/Octoprint, I was able to mount the SD card as a storage device and then ssh to the raspi and edit the smoothie config file and reset the board with M999 in the Octoprint terminal. I assume its not in the port for space saving. Again, I hope that I might be satisfied with ethernet solution.

3. PS_ON: I am working towards psu control with the PS_ON pin. With Octorprint, I used PSU control for turning on/off and power saving. I have a Pi-ATX psu hat that will take the trigger wire. (see http://git.io/PiTX if you want a pcb board, PM me).

4. Additional endstop trigger- I like having an estop when the machine goes out of bounds. I am trying to work through assigning a pin to E0 and wiring my switches in series NC so that if one trips, the trigger gcode macro will run.

Edited 2 time(s). Last edit at 05/09/2019 03:37PM by sinned.

Can I use this on an SKR v1.3?
Ok, I see it can. Do I have to build this myself?
Found the binary for the latest version.
Will give it a go and report back if I get it working

Edited 2 time(s). Last edit at 05/09/2019 02:04PM by jay_s.

---

Based in Darlington, North East

Quote
sinned
I am happy to report that the menu file from here -

https://github.com/mudcruzr/Duet-Maestro-12864-Menu-Files

work really well. I tweaked them a bit for my setup, but the basic framework is there. 90+% of a functional printer is in the menues.

There are a few things that I am still trying to work through-

1. Octoprint consistently experiences a serial exception. I have looked at the suggested fixes, so far nothing has helped. Hoping that the ethernet daughter board will work and then I wont have to rely on Octoprint.

2. Access to the SD card / Sneakernet. I miss this the most from Marlin 2.0 and smoothie. With raspi/Octoprint, I was able to mount the SD card as a storage device and then ssh to the raspi and edit the smoothie config file and reset the board with M999 in the Octoprint terminal. I assume its not in the port for space saving. Again, I hope that I might be satisfied with ethernet solution.

3. PS_ON: I am working towards psu control with the PS_ON pin. With Octorprint, I used PSU control for turning on/off and power saving. I have a Pi-ATX psu hat that will take the trigger wire. (see http://git.io/PiTX if you want a pcb board, PM me).

4. Additional endstop trigger- I like having an estop when the machine goes out of bounds. I am trying to work through assigning a pin to E0 and wiring my switches in series NC so that if one trips, the trigger gcode macro will run.

RRF doesn't support mounting the SDCard as a MSD, that is also why it's not included in the port.


DC42 has made some new changes in the upcoming RRFv3, and one of those changes should make it a lot easier when configuring endstops in the future - you will be able to directly specify the pin to use on M574.

If I load this on an SKR v1.3, will I be able to set the driver current using SPI?

---

Based in Darlington, North East

Quote
jay_s
If I load this on an SKR v1.3, will I be able to set the driver current using SPI?

No, currently there is no SPI stepper driver support compiled into the LPC port. It currently only supports manual and digipot for setting driver current, and only manual is supported for setting driver microstepping.

Quote
flydeprutten
The LAN8720 is serial and, as I can see, it is a serial interface that LPC1768 needs. I ordered a LAN8720. Then we'll see. :-)

Any luck on this? I am trying to make a cable adapter to mate the two - i dont have the right connectors on hand just yet.

Quote
sinned
Any luck on this? I am trying to make a cable adapter to mate the two - i dont have the right connectors on hand just yet.

Unfortunately I haven't got it yet. I was too focused on price, and did not notice that the product was shipped from China.

I'm probably just going to use a dupon connector to connect it to my Re-arm.

Edited 1 time(s). Last edit at 05/16/2019 03:24AM by flydeprutten.

OK. Today I got my LAN8720 in the mail. I made a cable to connect it to my re-arm and it works. However, the problem is that it is insanely slow. My upload speed is approx. 100kb/s, and since the web server only allows one connection at a time, I get timouts in chrome. However, I can make it work in Firefox.

i have a problem with that status.temps.heads is an empty variable in the ajax call that module.js makes, and that causes the interface to fail, but i suspect it to be a config error. However, I am unsure if the slow network is due to the LAN8720 module, my cabel, or the controller itself.

Quote
flydeprutten
OK. Today I got my LAN8720 in the mail. I made a cable to connect it to my re-arm and it works. However, the problem is that it is insanely slow. My upload speed is approx. 100kb/s, and since the web server only allows one connection at a time, I get timouts in chrome. However, I can make it work in Firefox.

i have a problem with that status.temps.heads is an empty variable in the ajax call that module.js makes, and that causes the interface to fail, but i suspect it to be a config error. However, I am unsure if the slow network is due to the LAN8720 module, my cabel, or the controller itself.

I only get about 100KB/s (as reported by DWC) upload speeds when testing with 100MB file (I haven't tried with larger files as it would take too long to upload). On these LPC boards, there are 2 main issues that contribute to the the poor speeds: SDCard connected via SPI (there is no support for the much faster SDIO on the microcontroller) and lack of memory (only a total of 64KB ).

To get everything to fit, the write buffer for the SDCard was reduced to 512 bytes - this also matched the library used for SDCard which only supports single block access (512 block size). There is a multiple block access command which supposedly achieves better speeds, but that of course requires extra multiples of 512 bytes. Then there is the networking which is configured for low memory usage instead of high throughput:

• MTU had to be dropped down to 586 (the minimum that TCP+ requires to use DHCP).
• MSS also dropped to 512 (to match our write buffer).
• Only 5 616 byte buffers are allocated to the EMAC.
• Each TCP socket is configured to use 2xMSS buffers (only 1 for RX and 1 for TX).
• Http is setup for 2 sockets.

In total, the networking side of things for RRF (including task stacks, responders etc etc) is currently all squashed into around 15KB of RAM.

I use the web GUI a lot as part of testing and do not see any timeouts (firefox or chrome), and only the occasional DWC dropout (usually cause i've run some commands that fill up the output buffers). If you mean timeouts as in the web pages aren't even loading then there probably is some other issue (maybe something like picking up some noise on the wires etc). Also, keep an eye on the link led on the eth socket to make sure the link isn't dropping out (a lost link will trigger a reset of the networking by ending all sockets and attempt to obtain a new IP Address etc etc). Ping is enabled so you could keep a ping running and watch that too.

I mean timeouts when I load the page. As I can see, I get it on viewmodel.js, as it is the last file that is being requested, and chrome therefore gives a timeout, as it does not get downloaded in time.

When I get home I will do a ping test, and then I could design a pcb that could act as a bridge between the re-arm and the ethernet module. this would remove that uncertainty. :-)

Quote
flydeprutten
I mean timeouts when I load the page. As I can see, I get it on viewmodel.js, as it is the last file that is being requested, and chrome therefore gives a timeout, as it does not get downloaded in time.

When I get home I will do a ping test, and then I could design a pcb that could act as a bridge between the re-arm and the ethernet module. this would remove that uncertainty. :-)

Ahhhh, I think I know whats wrong. Did you grab the www from the SD-Card folder? Looks like there is a very old version of DWC in there. That explains that status.temps.heads error as well. I didn't even know that was there, i only found it from searching for "status.temps.heads". Also, make sure to use the configurator to generate a set of config files (if you haven't already) rather than using those in the SD-Card folder as they are few years old too.

Can you download and unzip DuetWebControl-mini.zip to the /www/ dir on the SDCard, it's the new DWC2.0 with few minor edits to support the LPC version?

Quote
sdavi
Ahhhh, I think I know whats wrong. Did you grab the www from the SD-Card folder? Looks like there is a very old version of DWC in there. That explains that status.temps.heads error as well. I didn't even know that was there, i only found it from searching for "status.temps.heads". Also, make sure to use the configurator to generate a set of config files (if you haven't already) rather than using those in the SD-Card folder as they are few years old too.

Can you download and unzip DuetWebControl-mini.zip to the /www/ dir on the SDCard, it's the new DWC2.0 with few minor edits to support the LPC version?

That makes sense. :-)

I totally missed that. I will also try that when I get home. Thanks!

Thanks for the help. Everything now works as it should. Or at least as expected.

You were right there was an error 40. After I made a configuration file and used the right DWC it worked. However, I can't upload larger files without it failing, but I have a toshiba airflash card so it's not a big problem.

I can hereby confirm that the LAN8720 works as a network module for the Re-arm.

Quote
flydeprutten
I can hereby confirm that the LAN8720 works as a network module for the Re-arm.

Hurray!

How did you wire up the module? Can you take a look at this and give me your thoughts ?



Do we do anything with the RSOUT pin on the bottom left of the jumper?

Thanks

sinneD

Edited 1 time(s). Last edit at 05/25/2019 02:18AM by sinned.

Quote
sdavi
To get everything to fit, the write buffer for the SDCard was reduced to 512 bytes - this also matched the library used for SDCard which only supports single block access (512 block size).

I am confused- does this mean that the SD card in the Graphical LCD is functional?

I thought that it was not available.

sinneD

Quote
sinned
Hurray!

How did you wire up the module? Can you take a look at this and give me your thoughts ?

SJXISma.jpg

Do we do anything with the RSOUT pin on the bottom left of the jumper?

Thanks

sinneD

This is how i connected the LAN8720 to my Re-Arm:



I made the mod on the LAN8720 module where I connected the RX_ER to NC.

Quote
sinned

Quote
sdavi
To get everything to fit, the write buffer for the SDCard was reduced to 512 bytes - this also matched the library used for SDCard which only supports single block access (512 block size).

I am confused- does this mean that the SD card in the Graphical LCD is functional?

I thought that it was not available.

sinneD

Yep, that was implemented about a year ago when sharedSPI was ported. I just plugged mine in and can confirm it's still working. As long as its connected to the SPI (SSP0 - 0.18,0.17,0.15) pins and the right pins are setup for the chip select and card detect in the board.txt.

Mount with M21 P1 and the filenames etc are referenced by prefixing with 1:/ i.e. list files on 2nd card with M20 P"1:/" . Unmount with M22 P1

Quote
sinned

Quote
sdavi
To get everything to fit, the write buffer for the SDCard was reduced to 512 bytes - this also matched the library used for SDCard which only supports single block access (512 block size).

I am confused- does this mean that the SD card in the Graphical LCD is functional?

I thought that it was not available.

sinneD

Not the sd card on the LCD. The on-board sd card.

Reprapfirmware can use the sd card, but you cannot access the sd card on your computer via the usb cable, as you can on Marlin.

edit:
Nevermind. See SDAVIs answer above ..

Edited 2 time(s). Last edit at 05/25/2019 04:09AM by flydeprutten.

Has anyone set up a thermostatically controlled fan for hot end? If so, what pin did you use? I have not been able to get it work right with any of the available pins.

I am thinking that the best way might be to actually use a 5V triggered MOSFET off of one of the servo pins.

Any suggestions?

EDIT: I am having trouble reconnecting the PS_ON pin and getting it to function. Anyone have any luck with it?

Edited 1 time(s). Last edit at 05/29/2019 07:21PM by sinned.

Quote
sinned
Has anyone set up a thermostatically controlled fan for hot end? If so, what pin did you use? I have not been able to get it work right with any of the available pins.

I am thinking that the best way might be to actually use a 5V triggered MOSFET off of one of the servo pins.

Any suggestions?

EDIT: I am having trouble reconnecting the PS_ON pin and getting it to function. Anyone have any luck with it?

To use the PS ON, you need to add the pin you want to use to the board.txt config. Looking at the pinouts for the ReArm it says pin 2.12 is PS_ON so you would need to have:

atxPowerPin = 2.12;

After some testing, currently the output doesn't match whats needed for ATX supply and is unfortunately reversed, so M80 and M81 do the opposite. I've just added fix for that problem by adding a new config entry to allow the output signal to be inverted, which will be included in the next version RRF v3.


I just tried the thermostatic control on my bench setup (using LED instead of fan) and it appears that it's working correctly. To use a spare pin to control a fan you'll need to add a mosfet. Note that the LPC pins only output 3.3V, but I do notice that the rearm also has a spare pin labelled SER4 (P1.18) which is listed a being 5V level shifted according to the pinout diagram. So if your not using SER4 then you'll need a mosfet compatible with 3.3V.

Setup a 2nd fan pin in the board.txt file such as:

fan.pins = {2.4, SPARE_PIN_HERE};

You can also add that spare pin, if its not a hwpwm pin, to the fastPWM array in board config too if you need to use PWM to run the fan at a speed other than 100% or 0%.

then add to config.g something like:

M106 P1 S1.0 I0 F250 H1 T45; 2nd fan, monitoring extruder temperature, trigger at 45deg

Edited 1 time(s). Last edit at 05/30/2019 04:42AM by sdavi.

thanks. you confirmed what i was seeing. I keep forgetting that things are 3.3V instead of 5V.

EDIT: Rough protoype boards works as described below.



1. PS_ON- I was using 2.12, its 3.3V . To turn on a ATX_PSU, we need to ground the Green PS_ON wire on the PSU. I think a mosfet or transistor would do the trick. I need to think about that a bit....

[reprap.org]

I am doing this too - [github.com]

to drive the raspi and power the ReArm and RAMPS and LCD by leaving the ReArm jumper on Internal. Turning on the PSU then feeds 12V to everything else.

2. 2nd fan- you are right, I think it needs a another mosfet or even mosfet/driver. Since its Hotend cooling fan, then it can just be 0 or 100% on.

Mosfets: I was going to 'recycle' a old RAMPS board with burnt pins- it has STP55NF06L on it, and if I read the datasheet right, VGS at levels as low as 2.5V should easliy sink 15A at 12V, more than enough to run a fan.

[www.st.com]

Edited 6 time(s). Last edit at 06/01/2019 11:42AM by sinned.