Duet3D / RepRapFirmware

OO C++ RepRap Firmware
GNU General Public License v3.0
940 stars 532 forks source link

Adding support / porting RepRapFirmware to Da Vinci Jr 1.0 #190

Closed pyr0ball closed 2 years ago

pyr0ball commented 6 years ago

I've been working with a group of devs over on Soliforum to try to port Repetier to the board in this printer, needless to say without success as it's running a CPU that only RRF has compatibility for (ATSAM4E8E).

We've successfully mapped out the pins for this board and had started decoding communications between the main CPU, and a small slave microcontroller which is used for extra GPIO (including temperature sensing and heater gating)

I've got one of these printers I don't mind destroying, all wired up for serial and jtag debugging, and can do the compiling and testing if we could get some assistance with porting this firmware over.

Here's the forum post with our current body of work on this board: http://www.soliforum.com/topic/13769/davinci-jr-repetier-port/

Thanks in advance!

dc42 commented 6 years ago

Hi, what aspect of RRF do you need assistance with at present?

pyr0ball commented 6 years ago

Well we need a pins.h mapped for this board at the very least, and we need help in figuring out how to get the main ATSAM4E8E to communicate with the slave microprocessor (NXP LPC1115) to handle thermal sampling and HE0 control.

I saw that duetWifi uses a similar relationship for one of its LCD modules, but I'm not experienced enough to be able to adapt that code for this use case.

Edit: we know there is a direct serial UART connection between the two processors, and I've done a few captures trying to get a handle on it, but it appears to be straight binary messaging between the two.

On Fri, Jul 6, 2018, 1:16 AM dc42 notifications@github.com wrote:

Hi, what aspect of RRF do you need assistance with at present?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/dc42/RepRapFirmware/issues/190#issuecomment-402962289, or mute the thread https://github.com/notifications/unsubscribe-auth/AIFv9YY_uXqY8bQ61oKcNNMiS_9n2q0Eks5uDxzzgaJpZM4VE8fX .

dc42 commented 6 years ago

The pins.h file should be easy enough for you to construct. I suggest you fork the v2-dev branch of RRF and add a new configuration for your control board.

The SAM4E has 2 UARTs and 2 USARTs. Which one is connected to the secondary processor? There is support for the UARTs in CoreNG. On the Duets, the USARTs are used to support additional SPI buses.

Does your control board have a SD card socket, and if so, do you have it working?

Regards David

On 6 July 2018 10:22:21 CEST, pyr0ball notifications@github.com wrote:

Well we need a pins.h mapped for this board at the very least, and we need help in figuring out how to get the main ATSAM4E8E to communicate with the slave microprocessor (NXP LPC1115) to handle thermal sampling and HE0 control.

I saw that duetWifi uses a similar relationship for one of its LCD modules, but I'm not experienced enough to be able to adapt that code for this use case

On Fri, Jul 6, 2018, 1:16 AM dc42 notifications@github.com wrote:

Hi, what aspect of RRF do you need assistance with at present?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub

https://github.com/dc42/RepRapFirmware/issues/190#issuecomment-402962289, or mute the thread

https://github.com/notifications/unsubscribe-auth/AIFv9YY_uXqY8bQ61oKcNNMiS_9n2q0Eks5uDxzzgaJpZM4VE8fX .

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/dc42/RepRapFirmware/issues/190#issuecomment-402963667

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

pyr0ball commented 6 years ago

I'll have to check the datasheet to say which it is.

I've only done minor changes to Marlin firmware before, and have almost no experience with RRF thus far, so I'll probably need some validation support after I make the pins.h

Also we know that the heater and thermal sensing pins are definitely handled on this secondary processor, so I'm not really sure how to incorporate them into the pins.h

I'll get the partial schematic I made uploaded here for reference along with the pin map

Pins map Google sheet

DaVinciJr_Research Schematic (partial).pdf

Edit: ok after reviewing my research notes, it looks like the serial connection used on the SAM4E is on pins 73/114 (symbols PA5/PA6) which the datasheet shows as connected to UART1.

My guess is that UART0 is assigned to USB communication I/O.

There is an SD card slot, but it's connected directly to the SAM4E using it's dedicated high-speed SPI bus

pyr0ball commented 6 years ago

Just checking in, wondering if there's any interest in interest in this

dc42 commented 6 years ago

Have you considered making a post in the Controllers section of the forum at reprap.org? It would get much more visibility than this issue log.

If the SD card slot is connected to the HSMCI pins of the SAM4E then it should work with RepRapFirmware already.

If you want to make a pins file for RRF, your first task is to complete the listing of what each pin on the SAM4E is used for in your Google sheet.

pyr0ball commented 6 years ago

We did try flashing RRF to it at one point, but because of the heater and temperature pins being connected to the second processor, the heater cartridge heats up out of control.

Anyhoo I'll take your advice and gather all of our information into a post on reprap forums.

Thanks!

WannaBAcoder commented 4 years ago

Just curious if any progress has been made on this front yet? Trying to decide if I should just use a different motherboard/marlin and rewire the LCD/hotend to get the printer working without all of the faulty sensors that cause issues.

pyr0ball commented 4 years ago

I haven't recently as I've been working on other projects

hardgeek95 commented 2 years ago

Is possible made some mod to the board, extracting the second processor that control temp and heather element and connect it direct to principal processor?

T3P3 commented 2 years ago

please discuss this on the forum rather than on Github issues.