Has anyone tried to run Marlin on a Chitu F Series V3.9 Board? http://www.cbd-3d.com/en/prod/fdm.shtml
It came with a 3.5 TFT Color TouchScreen on my QIDI X-One. Running Marlin would be a huge improvement but I'm not sure if it's even compatible...
I wanted to check if this was possible before swapping it out for an MKS SBASE or Similar Board.
Currently Marlin only officially supports 8 bit controllers but ... there's a LOT of work going on to remedy this.
Marlin 2.0 with 32 bit support is supposed to be out in early July. I don't know what it'll support or how functional it'll be.
Take a look at Issue #3851. The STM32 is talked about a lot in there.
There's several 'unofficial" Marlin forks being worked on currently for STM32, LPC1769 & SAM3X processors.
I've just put the Marlin fork MK4due on my Arduino Due & RAMPS-FD combo. I expect to try some steppers on it in a couple of days.
I've just put the Marlin fork MK4due on my Arduino Due & RAMPS-FD combo. I expect to try some steppers on it in a couple of days.
If it wasn't for this comment... I would have said the Re-ARM board with a RAMPS board is in the lead. But there is activity across the entire 32-Bit space. As soon as the folder and file re-organization happens, we are going to see a lot of progress on the 32-bit side of things.
Has anyone tried to run Marlin on a Chitu F Series V3.9 Board?
That board looks very interesting. But I didn't see a price for it. And more importantly, I didn't see anything about what type of build environment it needs for the firmware. With that said, many of the current 32-bit efforts are doing just fine with Atom & PlatformIO. I do not have my Re-ARM board connected to a printer yet, but Marlin is running on it along with the code to manage the Graphical LCD Display. Progress is being made fast. So this board looks like something people will want to put a HAL in place.
To use the cheap Chinese boards requires some reverse engineering, because
they typically don't publish source code, schematics, or even a pin
mapping. They are about as closed as you can get, but at least they don't
scrub off the part numbers from the ICs. They also tend to have a few basic
hardware faults that can be awkward to fix.
However, building firmware just needs any toolchain of generating Cortex M3
code, and flashing the chip is probably easily done with off the shelf
tools written for STM32 chips using a USB-serial adapter. Sometimes the
boards have pins exposed for JTAG, which makes things easier for
development.
One thing is for sure though, users buy based on price first, and then look
for third-party support when they find the manufacturer's are unable or
unwilling to provide any useful support. I bought one of the cheap
Smoothieboard clones, it's still waiting for me do something with it.
On 8 July 2017 at 16:03, Roxy-3D notifications@github.com wrote:
I've just put the Marlin fork MK4due on my Arduino Due & RAMPS-FD combo. I
expect to try some steppers on it in a couple of days.If it wasn't for this comment... I would have said the Re-ARM board with a
RAMPS board is in the lead. But there is activity across the entire 32-Bit
space. As soon as the folder and file re-organization happens, we are going
to see a lot of progress on the 32-bit side of things.That board looks very interesting. But I didn't see a price for it. And
more importantly, I didn't see anything about what type of build
environment it needs for the firmware. With that said, many of the current
32-bit efforts are doing just fine with Atom & PlatformIO. I do not have my
Re-ARM board connected to a printer yet, but Marlin is running on it along
with the code to manage the Graphical LCD Display. Progress is being made
fast. So this board looks like something people will want to put a HAL in
place.—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/7264#issuecomment-313861164,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA7VR-tvmRhmQjZADr866lyC6bQJX_Anks5sL5pdgaJpZM4ORndi
.
To use the cheap Chinese boards requires some reverse engineering, because
they typically don't publish source code, schematics, or even a pin
mapping. They are about as closed as you can get, but at least they don't
scrub off the part numbers from the ICs.
It looks like this company is trying to sell the hardware components to build an entire printer. If that is the business model, it would be smart to give developers the schematics so we can get the firmware talking to all the different pieces. Without a pin mapping... It is too hard to do anything with it.
Let me add some more detail here. The ChiTu V3.9 board comes with the QIDI X-One printer that runs on a closed source repetier-firmware (i'm guessing)... I got one used off ebay at a great price.
This all came about with me wanting to PID tune the hotend as the temp fluctuation is about 4 degress +/-. I spoke with Qidi and Chitu support and they won't give out the instructions to enable eeprom saving so the autotune PID command does not run in the terminal command.
I translated the Chinese update file here but this only allows a manual PID settings.
As for price the only place I have found it is on eBay here. It really doesn't justify the price at all if you have no control over such important settings.
The QIDI X-One is a really well build and nicely thought out machine, but this board just kills it for me. So I figured I would throw this out there before I committed to purchase an open source board.
Well, just as a comparison, the Re-ARM board with a RAMPS board and step sticks can probably be done for under $60. And you get all the documentation for mapping pins to the firmware. And that will be one of the very active configurations when the Marlin file and folder layout is done. And it wouldn't surprise me if somebody with the ChiTu board uses M43 to map the pins. It just takes time and an interest.
@Roxy-3D where can I get a kit to start testing 32bit Marlin ? What is exactly the status of it ?
where can I get a kit to start testing 32bit Marlin ?
What I have is a 32-Bit LPC-1768 based board. It is the Re-ARM board. It was originally sold here: https://www.kickstarter.com/projects/1245051645/re-arm-for-ramps-simple-32-bit-upgrade But now I believe they are in production and being sold here: https://www.panucatt.com/Re_ARM_for_RAMPS_p/ra1768.htm for $45
With this, you just plug in an existing RAMPS v1.4 board with step sticks... And you are good to go...
What is exactly the status of it ?
I have my board loaded with Marlin running on it with a Graphical LCD Display. I do not have it connected to a printer yet. The work to get the Re-ARM board running Marlin was done by @p3p based on Bobc's earlier work.
The branch I have running on the board is here: https://github.com/p3p/Marlin/tree/32bit-bugfix-1.1.x-LPC1768 but by the time you get a board, you will want to be using the official main Marlin branch. (As part of the folder and file re-organization, the 32-Bit HAL's will be part of the main code base. )
If you start reading here... You can see the current thinking and status of things: https://github.com/MarlinFirmware/Marlin/pull/7028#issuecomment-311499644 Even though I can see Marlin is running on my board and I can adjust the Feed Rate and such and see it adjust on the LCD Panel, I don't have mine connected up to a printer yet. For me... one of the first things to do is get a substitute in place for the EEPROM. (The reason being UBL needs EEPROM to hold the mesh data and I'll be making sure UBL runs on the 32-bit boards) But even that is not too big of a deal. When the 32-bit HAL's are part of the main code base, as each problem gets fixed, in many cases everybody with a 32-bit board benefits. I expect progress to happen fast as soon as the file and folder re-organization happens.
Another thing that needs to happen is support for the 20x4 LCD Panels. That previously mentioned branch does not compile with 20x4 LCD displays yet. But I suspect that will get fixed pretty quickly.
But until then... I'm holding back. It is too hard to operate in a one-off branch.
Incidentally... The Cohesion-3D board will be fairly tame to bring up once the Re-ARM is fully functional. It has a LPC-1769 processor. So other than moving some pin numbers around, and changing some timer numbers, it probably comes up quickly: http://cohesion3d.com/cohesion3d-remix/
It takes a little bit of time to figure out how to use the 32-bit tool chains. Right now, the Re-ARM stuff is using PlatformIO inside of Atom. It seems to work pretty well and be fairly compatible with what is currently in place with Arduino.
where can I get a kit to start testing 32bit Marlin ? What is exactly the status of it ?
Get an Arduino Due clone for 13.77€ and plug it into RAMPS. Steppers work (IIRC) and you can get the heater mosfets working too if you change them out. Or use external ones.
Get an Arduino Due clone for 13.77€ and plug it into RAMPS.
Really... that is just really bad advice. smh
To save time, you could just burn the euros. Or better give them to a
charity :)
Would you at least care to elaborate? If the steppers work and the heaters work, then that is the basic functionality already. Are you saying the clone Due wouldn't work? Or are you saying using it with a RAMPS wouldn't be good enough?
I am saying that if you plug a standard RAMPS into a Due it will BREAK the
Due. Due runs at 3.3V, RAMPS is 5V only.
You seemed so sure that I had to test again. So I plugged a cheap unmodified RAMPS into my cheapo Due clone and loaded the p3p PR Marlin into it. I get the usual M503 boot post. I get a varying temperature read. It's not correct but at least it's reading something. I can turn the D10 output on from Pronterface but the mosfet being stock won't fully turn on. I can even drive the X-axis with a G1 command.
Is my Due still working after the test. Yes.
Why? Because there wasn't a single piece of hardware sending a signal into the chip. If I had plugged in an endstop, I would have had to do level shifting, but that wouldn't stop you from testing the Due fork and is only a minor inconvenience. RAMPS alone is nothing more than a dumb breakout board and alone will not break anything.
@3daddict going back to your question, there are 2 forks of Marlin HALs for STM32, + a port from STM for their DEV board.
Possibly one of those, or even all of them could work in that board given the correct configuration, but without the schematic to see what MCU pins are connected to what, you wouldn't be able to configure the firmware to run in the board.
If you find the schematic, that would be a good start.
I am currently working on a HAL based on libmaple, that should work in F103, F303, F407 and a few more. Chriss Barr has another fork that that a HAL for the STM32Generic core. And STM themselves used no Marlin HAL, and instead modified Marlin to use their HAL, so should be portable to other MCUs with a few changes.
My fork compiles and communicates, but I don't have a board to connect steppers, so I am waiting on an order from China to test it out.
@victorpv I have emailed [email protected] as I have an open dialogue trying to get them to enable save to eeprom in the stock firmware. They do not want to give people open access so they stoped replying to those eeprom inquiries.
I have now asked them for the board schematics and pin map to see if they will share that information, but I'm doubtful.
Let's see if I get a reply back in the next couple of days.
STM32 mcus don't have eeproms, so unless they added one on board, there would be no eeprom to save to. It can be emulated on flash, but is not ideal since flash wears out faster. Let's see if they give you the schematic, I don't see why not since they still sell the board even if you install a differnet fw, but perhaps they just don't want their design copied for cheaper, which other chinese vendors would probably do in a blink.
STM32 mcus don't have eeproms, so unless they added one on board, there would be no eeprom to save to. It can be emulated on flash, but is not ideal since flash wears out faster.
As soon as Marlin v2.0.x comes out it will have the new file and folder layout with the 32-bit HAL's included. At that point, one of the first things I'll do is put in code that uses a file on the SD-Memory card for EEPROM simulation. Probably any 32-bit board that has an SD-Memory card slot will be able to use the new code.
@victorpv well that would explain why they told me auto pid tune was complicated.
Hopefully they reply with some more information but I'm guessing there will be crickets in the background on this their reply.
I may just hold off on swapping the board until Marlin v2 is out and I can learn more about the 32-bit Boards. Also looking into the Re-ARM board as well, very interesting.
Also looking into the Re-ARM board as well, very interesting.
The more people that have Re-ARM boards, the better! Long term it is clear the software will run on many 32-bit boards. But initially, if we have a platform that has a bunch of developers and a following of users all on the same hardware it will make things easier. My vote is you run out and get a Re-ARM board! :)
If you are planning to test or develop, then what Roxy suggest may be a good idea if you want to get going.
For STM32 I believe the only real open board available right now is the STM official one. A bit pricey, but looks like a very good quiality board:
http://www.st.com/en/evaluation-tools/steval-3dp001v1.html
It runs in a custom version of Marlin, but very close to the official and totally open source as one would expect.
As suspected no reply back from Chitu support on the board mapping.
Here is the Company info if anyone has better luck than me;
Homepage: http://www.cbd-3d.com/en/index.shtml
Email: [email protected]
Document Database: http://www.chitucloud.com/index_en.html
It would have been nice not to have to swap out the board on my QIDI X-One, oh well...
The MCU in those pictures is an STM32F103ZET, if someone with one of those boards can draw the schematic, it's likely we can make it work with the HAL I'm writing for the F103 series.
Not sure how the display is connected and what type is it, but the FSMC is working fine in the stm32duino/libmaple core, and there are other parallel display drivers working too at high refresh rates.
Well I got a reply back from Chitu Support;
chitu board are not open source, so i am sorry to tell you that.
2017-07-14
support
I'm not capable to draw a schematic so I might be pulling the board out and shelfing it for awhile.
Well if someone is shelving one of those Chitu boards and wants to send it to me to try to draw the schematic I can give it a shot. May take me a while to complete, but I will return the board back to the owner, and hopefully later we may be able to have Marlin running on it.
@victorpv that might be do-able for me when I actually pull the board. I'm upgrading my other printer so I'm still using the one with the Chitu Board for a while. How can I DM you my info?
I don't see a way to send PMs in Github, just send an email to [email protected]
No hurries on the board, only if you eventually remove it for other reasons.
I have to start my stm32 hal with a RAMPS plugged to generic stm32f1/f4 boards, debug it, etc.
After it works fine with normal generic parts, then will probably be worth trying to make it run in one of those Chitu boards.
Im using the 3DSway Lerdge, a recent chineese board. The firmware is ok too, with nice 3.5 touchscreen and nice features. But as it is closed source. It is based on STM32 too and the quality of the board is the best I have seen before. Overall and performance is outstanding. It needs marlin :D.
@moracabanas whats the MCU on it, and do you have an schematic?
@victorpv sorry for the late, I don't know about the FPU on the lerdge board but it's based on STM32F407ZGT6. It has FPU and DSP. All the info is gathered on the Aliexpress page and the official website. I have the board with his closed firmware and the quality of components is ashtonishing. I like it by the fact you can use whatever drivers you want, for example the MakerBase LV8729 has the best silence-microsteps-price-quiality overall. The board has also high quiality Texas instrument dedicated current controller and many more high-end quality construction. It could be great to have marlin32 ported to it.
@moracabanas that's what I was asking, the MCU model. Seems like a nice board, but I still can't understand why they pick these powerful chips and then make a board with the minimum number of outputs.
I'm designing my own board around a 407VET6 cpu (100 pins vs 144 for the zgt), and I still have enough pins to run up to 8 steppers 4 heater outputs, 4 thermistors... and a bunch other things.
There is a board from STM themselves, I could call that the best bang for your buck.
http://www.st.com/en/evaluation-tools/steval-3dp001v1.html
Top notch quality, enought outputs, WIFI, open source, open hardware. ESD protection all across (USB, thermistor pins, end stop pins...). It's a bit more expensive than that Lerdge, but honestly I think they are selling it at a loss since it's way overbuilt compare to any board in the same price range.
That's just my personal opinion, not trying to convince anyone that's the best board.
BTW, that lerdge board probably can run on the HAL from Chriss Barr already if you can get the schematic to figure out what pins drive what. I haven't tested my HAL with F4 at the moment, only F1, and I know I there is a couple of things I need to change for it to work on the F4, since I am using the libmaple based F4 core.
Ok I give in !! I have a Tronxy X5S with the new Chitu Board and touch screen conversion kit also the USB conversion as the Chitu board does not have one .Can I throw this lot in the bin and buy an original Aurduino to replace this mess ? It seems logical , I am no tech genius but I can read instructions ,lacking with these kits ! ,I hope some one out there can help .
@3daddict @thinkyhead can we add this one or do we need a pins file maybe?
@3daddict @thinkyhead can we add this one or do we need a pins file maybe?
@victorpv can we look into this again? Do we need a pins file or do you have it saved from when you had the board?
Guys sorry I haven't been very active, extremely busy with other personal stuff. I saved the pins and added the board the board file to Marlin a while back in a PR I believe was merged. I did print fine, only thing I never got around to test was the thermocouple port, and the LCD display which is a parallel one that I doubt Marlin supports at this time. Check the board files, there should be one for Chitu, if not let me know and I'll post the pins in this thread. I believe there have been changed to Marlin to use a different stm32 Hal, I tested with the libmaple based Hal, and still using my prototype board for printing and laser engraving since last year without a single hiccup. The Chitu board printed fine back then in a test, should work fine now as long as there is a functional stm32f1 Hal. Let me know in this thread of the board file is not already in Marlin
So I see the Chitu pins file @victorandueza - have you tested the touchscreen at all on it? Ill be testing it a bit more and looking to add a working config for the TronXY X3 thats using this.
I tried to compile a ChiTu3D Marlin firmware. I added an entry #define BOARD_CHITU3D 1821 //CHITU3D
in board.h and change #define MOTHERBOARD BOARD_CHITU3D
in configuration.h but I get several errors that pins are not declared. Has someone an advice for me.
I have one of these I need to work on a bit sometime soon... Its about 5th in my project list though....
any progress on this? @InsanityAutomation
any progress on this? @InsanityAutomation
A discord user has actually gotten a working port with the touchscreen going, so good chance itll make it back to us sometime in the near future :) When he opens a PR ill update this thread.
I've broken the encryption on the built-in chitu bootloader and can load firmware from SD card now. If someone has a link to the port that supports this, I'd love to test updating. I was able to get Marlin 2.0 running without LCD or SD card, but all the advanced features didn't work.
Sounds like just a matter of getting a proper pins_CHITU_39.h
file together now!
Sounds like just a matter of getting a proper
pins_CHITU_39.h
file together now!
I think that's fine, it's the touchscreen setup that ftoz on discord was still working on. It will be nice to have this one working too though!
The Tronxy board spits out the LCD ID at startup if you have a debug monitor hooked to the CH340 at 115200. LCDs supported by Chitu’s firmware (which sure looks like it’s got chunks of repetier in it) are SSD1963, ILI9341, ILI9486, and ILI9488. I’ll create a PR to add the board LD, encryption script, and environment.
On Oct 8, 2019, at 7:37 PM, InsanityAutomation notifications@github.com wrote:
Sounds like just a matter of getting a proper pins_CHITU_39.h file together now!
I think that's fine, it's the touchscreen setup that ftoz on discord was still working on. It will be nice to have this one working too though!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/7264?email_source=notifications&email_token=AHVGS4M3JYS4NPQNIDQHSALQNU7VRA5CNFSM4DSGO5RKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAWJ57Q#issuecomment-539795198, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVGS4LDQSGZRE5G7FKAGXTQNU7VRANCNFSM4DSGO5RA.
Sounds like just a matter of getting a proper
pins_CHITU_39.h
file together now!I think that's fine, it's the touchscreen setup that ftoz on discord was still working on. It will be nice to have this one working too though!
Do you have any idea how to get in contact with ftoz? I would like to get this wrapped up and actually have an X5S now to test with. The existing pins file seems to match up for most things. I'm not sure where the battery backup sensor lives yet, but there are only so many pins left it could possibly be attached to.
The Chitu F seems pretty closer (or even the same) as the TronXY boards and TFT. You can try the CHITU3D_V5 and CHITU3D_V6 boards. It may work with the F series. Maybe some PIN need be changed... but most of the things should work, including the TFT.
Recently a user could get his QiDi woking with current marlin pins file, so I will closed this as looks like it's done.
Most helpful comment
I've broken the encryption on the built-in chitu bootloader and can load firmware from SD card now. If someone has a link to the port that supports this, I'd love to test updating. I was able to get Marlin 2.0 running without LCD or SD card, but all the advanced features didn't work.