PLANNING: New firmware

Samuel Pinches

I've written a blog post (read here) discussing the firmware situation for the A5S and A1. If you would like to join our team to create a new firmware, please post below!

aestrems

This is a good news, can’t wait to see what you guys can do! 

Richy_T

I might be in now that my A1 turned up. I am not sure how much commitment I can make at this stage. I could probably make the coffees or something

(I do have some relevant background though).

Do you have a decent picture of the board(s) with specs (memory etc)? It would be nice to have a rough idea what we're working with.

One more thing, you mention that the current source requires a $1500 IDE. Would it be a lot of work to move it over to a free/cheap IDE (assuming one is available)?

Samuel Pinches

Here's some excellent photos of the motherboard, taken by @DaHai .

Download the hires photos at this link.

Samuel Pinches

This motherboard is the same on both the JGAurora A5S and the JGAurora A1, here are the components:

• The main processor on the board is the STM32F103ZE
• There is a Winbond W25Q128JVS SPI NOR 16MB flash module
  
• There is also a tiny ATMLH614 EEPROM also used, of unknown capacity.
  
• The stepper drivers used are Allegro A5984 fitted with heatsinks properly fitted on the motherboard underside, thanks to the thermal pad on the bottom of the package.
  
• Nozzle heater and fan control mosfets are International Rectifier Power HEXFET LR7843, rated for up to
  
• Bed mosfet is a beefy International Rectifier Power HEXFET F2804S in a D-pak, rated to operate at up to a scorching 175ºC!
• USB to serial is the budget CH340G chip from WCH
  

Richy_T

Seems like there's some headroom to work with then. Raw 8-bit micros are pretty fast already so I'm not sure how much we gain from 32-bit print quality wise but certainly there is room for improvements. A redesigned, streamlined but more attractive UI would be an easy win. Pre-heating is a bit of a fuss at the moment (though I should check the manual if there's a better way to handle that). Bed leveling seems to be on the wishlist (though I am pretty happy with how easy getting the bed level was). I would like to see if we could get some integration with an ESP module (even the ESP-01 should be serviceable).

Are you thinking of tearing down the "dual brain" thing or working with it?

Also, do we know if the bootloader thing is pretty straightforward? I'm guessing a binary file on the SD card to update the firmware?

Samuel Pinches

Unfortunately, I won't have any time to commit to this, likely until the end of January.

Updating the firmware is easy, yes, just a binary file on an SD card.

An ESP looks easy to integrate via serial, even with the stock firmware: e.g. see here or here 

However, I don't know that we have enough people or resources to be able to create a new firmware from scratch? My dream would be to get one of these existing mainstream open source firmwares to work. At the moment, 32 bit 3D printer firmwares are a massive mess - I posted a little about this on my blog.

Here are a list of the potential options that I can see could be worth considering - ordered by what I think is most viable

1. Try to get the same Arduino 1.1.X firmware to work, as on the A5.
This could be easily possible using the STM32duino.com platform, and might be a nice easy win - to give people an option to play with in the meantime. I imagine that this would have to be run headless, with no colour LCD support - instead connected to a computer or raspberry pi for running control and interface. Alternatively, with correct pin mapping, and a custom cable, I'm sure it would be possible to connect a standard marlin-compatible black and white LCD to the A5S motherboard. There's a project that appears to have successfully done this on a different 3D printer model already here with a github repo here! ST Micro themselves created a dev board with a working version of Marlin here.

2. Get Marlin 2.0 working on STM32F1
The next best thing I think could be to actually try to help get the Marlin 2.0 HAL layer completed for the STM32 platform - it looks like this is not yet completed. 

3. Implement Smartto
Geeetech have created their own open source STM32 firmware, with support for a colour LCD interface. I wonder if it would be worth trying to implement this? It could also be an easy win potentially?

4. Recreate stock firmware with up to date marlin
I think the current firmware is based on a version of marlin that is so old, that I don't think it's worth trying to update it, but I'm sure it will definitely come in handy to understand pinouts etc. But, I wonder if there is a way we could copy the same "dual brain" architecture using FreeRTOS. However, this would be far, far outside of my skill level...

5. Adapt Smoothieware for STM32F1
The other major 32-bit 3D printer is Smoothieware. This is a popular firmware running on a few different boards at the moment, but not yet supported on STM32. There is a project that started but appears to have abandoned trying to get STM32 support developed. But, then there has been some recent progress....

Richy_T

It's tricky. I'm really not sure how complex Marlin is. It seems like it should be fairly straight-forward but the devil is in the details. I'd definitely like to keep the LCD. Certainly for monitoring if nothing else.

I guess another option would be to go full dual-brain and offload the controller stuff to a separate board running a full Marlin and keep the main board as just a user interface. That might be a bit nuclear though.

Samuel Pinches

Then maybe looking to #3 would be the best option to start with? The Smartto firmware supports the STM32F103 processor, and is designed for a colour touch LCD.

https://github.com/Geeetech3D/Smartto-Eclipse

They also a companion tool here: https://github.com/Geeetech3D/Smartto-Tool

Richy_T

Sounds like that would be a good place to start. I think it's important not to become too tied to one machine so that advances can be shared. I'll try and take a look into that project. STM is likely to be a bit of a learning curve for me. Not sure how far it is abstracted.

It's probably worth getting a feature list together so we can evaluate how suitable that approach is. I'll also take a look at that ESP stuff to see if that's what I'm looking at too.

aestrems

Sounds really interesting your conversation, it's outside of my skills but if you want to know a point of view of a standard user I think the #2 and the #3 are the most interesting points. They are a big step forward of the actual firmware and seems to be easy to handle for a standard end user. If the installation is easy and the improvement is a big step forward, a lot of people will consider to use this update. You know how much important is a community around the success of a 3d printer and this things helps so I just can say keep pushing guys

Richy_T

That is what I'm thinking of with the wireless. I'm not sure how it is integrated with that one 3d printer. I skipped through the video a bit but it didn't look like he had to reflash the main board? I am not sure where we would have the option to add the module on our boards but we should be able to come up with something.

Sounds like we could add something to allow pausing to change filament from some other threads I have seen you write in? I'm quite surprised that's not an option.

Samuel Pinches

Yes, the ESP speaks "gcode" over a serial connection to the main motherboard - basically doing the same thing as a raspberry pi with octoprint. Can do pausing that way for sure

Also, from Scott's post today on Patreon, it sounds like STM32F103 should already be mostly supported by Marlin 2.0. I reckon Feb or so, I'll get stuck into this if noone else beats me to it Smartto is still a good first goal though, because of the LCD support.

Richy_T

What I don't get is that he got the IP address to display on the LED. Like I say, I skipped around though.

I think that Patreon thing probably pre-empts other options. Going for Marlin is probably a better course unless there's some killer feature in other things. Then again, these things can often hit delays. Do you have a link to this Patreon project as I have no idea what he's doing?

I'm not too worried about the LCD support thing as it may not directly translate to ours. I have some ideas about what I'd like to see in the UI also. Though I guess the question is whether a Marlin release would be easy to integrate the LCD stuff into or whether we'd be faced with the dual-brain stuff again.

I might have a poke around so let's keep this alive. I'd like to see a basic "Hello World" thing going on with the LCD and also see that the original firmware could be restored.

One of my main deals with the ESP would be that it would be nice to get a text or some other notification when the print was finished. But it opens up many possibilities.

Samuel Pinches

You can put any message on the LCD (a marlin compatible LCD, not a colour touch LCD) using gcode too: http://marlinfw.org/docs/gcode/M117.html

Richy_T

Ah. That makes sense then I thought the gcode just controlled the mechanics. My printrbot has no LCD.

Quick question then: How is contention dealt with? I.e. if I am printing from the SD card, how is gcode incoming on the serial/usb dealt with typically? Sorry, this is getting a little off-topic. Never mind. Looks like there is a bunch of information on that linked site. I'll do some reading.

Richy_T

Just out of information, I appear to have a different version of the board. I am having Z-axis issues right now though so...

Richy_T

I got my z-axis fixed by replugging on the motherboard. While I have the case open (I'm just about to close it back up), I thought I'd take a picture just for information. Quality is not that great but it's almost legible. Although it has a different description on it, it looks much the same as the one you have up there.

Samuel Pinches

Interesting, thanks for posting the photo! Glad yours is up and running again.

jelot_it

I do not know if I'll be able to do it, but I'd like to help

Richy_T

Does the similarity of the board imply that the open A5 firmware would run on this? Or am I missing something? Did this newer board and firmware replace the old stuff in the A3S/A5/A5X?

Samuel Pinches

@jelot_it - welcome, any help would be appreciated! There's a new marlin 2.0 that I think would be the first thing to try to get working potentially... or see the post above here for some ideas you might want to explore.

@Richy_T - the A5/A3S/A5X have a common motherboard - the MKS Gen L, which runs on an 8 bit Atmega 2560 CPU. The A5S and A1 have a newer STM32 based 32 bit motherboard, so not directly compatible without some work. Plus, even if we do get Marlin working on the A5S platform, Marlin does not support colour touch LCD's - this is the reason the current A5S firmware is a hodgepodge of two firmwares - a very ancient version of marlin on the inside, wrapped in a newer firmware on the outside to run the touch LCD.

Richy_T

Samuel, have a look at the silkscreen on my A1 motherboard though. It says A5/A3S/A5X.

Perhaps they created a new motherboard intending to put it in those machines but decided to go with creating new model numbers instead of confusing everybody?

Samuel Pinches

So strange, who knows right! Regardless, with a very similar exterior, and completely different motherboard/firmware, most people are confused.... especially between A5S and A3S...

Richy_T

It astounds me that companies can spend so much time and effort developing stuff and fail to communicate the differences in models to their potential customers. Just a simple comparison grid would be great.

jelot_it

I think the marlin 2.0 is the best option for starting.

It seems to me that the project "Smartto-Eclipsed" has been blocked or at least they write on the readme "We decide to focus on the eclipse version in the future, hoping our users can use the firmware more easily."

I lost a bit of interest on this project by reading some issues:

1. https://github.com/Geeetech3D/Smartto-Eclipse/issues/4 
2. https://github.com/Geeetech3D/Smartto-Eclipse/issues/21 
3. https://github.com/Geeetech3D/Smartto-Eclipse/issues/22 
4. https://github.com/Geeetech3D/Smartto-Eclipse/issues/33 

for 3 and 4 it seems we would need "IAR Embeded Workbench" which is proprietary and not free (and I could not use it on linux).

I read in previous posts that marlin does not support color LCD... we have some information on our LCD? Some high-definition image or generic information on what do we mount?

Frezap

I would love Marlin 2.0 aswell!

My own preference is to get everything running as reliably as possible with octoprint.

Ill try to get the screen running on an raspberry pi, so i already looked around a bit.

On the board of the screen are two numbers:

JLT28010PCBA08

and

JLT181015048

Googleling these numbers leads to this screen module:

https://www.alibaba.com/product-detail/2-8-inch-new-LCD-screen_60786589106.html

Richy_T

I'm not familiar with that particular screen but you have to be careful since although some screens can be made to work with the RPi, it seems some are not particularly fast when used that way. I have one that's compatible with the Adafruit one and it works very well. I don't really care about getting it working with Octoprint though as the web interface works well for me.

Samuel Pinches

The problem with the LCD is that writing to a colour screen requires a lot of processing power - both speed and memory. Marlin is designed to run on low-power 8-bit CPU's so does not support that.

The driver chip on most of these cheap LCD is either the

ILI9325C or the ILI9341 (datasheets linked). These are quite flexible, and support a range of communication protocols. SPI communication is the most common one typically used. There's a fair bit of documentation around how to use them, so that should not be too hard to get up and running. Building a user interface however is substantially more difficult...

I agree that Marlin 2.0 in a "headless"/no LCD mode is a good first target for us to shoot for. I'm sure we will learn a lot doing that to guide us with what to do next.

Richy_T

I've worked a little with some of these. There are libraries for doing graphics on these in the Arduino IDE libraries so it might be worth looking there for guidance.

Samuel Pinches

@Richy_T - it depends on how much CPU it takes up. Being an ARM processor we might be able to get away with it without using a RTOS...