Ender-3S1 VS Marlin

What are those ones? https://github.com/CrealityOfficial/Ender-3S1/tree/3S1_Pro_HighSpeed I thought that everything is there

It may not. What's on the Creality github at https://github.com/CrealityOfficial/Ender-3S1/tree/main/Marlin is Marlin 2.0.8.1, and the config files won't match any other version without changing a few things. The current stable release version of Marlin is 2.1.1. The compiler checks the versioning of all the files, because the way some things work has changed in newer releases. Even the board names for the S1 have changed in later versions of Marlin, because there are at least three possibilities, not just one, and none of them have the same name as the one defined in 2.0.8.1.

That is correct, you either have to use the S1 screen or an E3V2 screen. I remember helping someone with the firmware and they were able to get octoprint working with their setup. Here's the thread. The stock S1 Pro firmware was released by Creality. I think there's a way to get things working with octoprint just by editing some config. I would try that first since it's pretty much free before spending money on getting a different screen.

I would say stay with the stock if it is working for you. When you're ready to dabble with firmware, then sure you could look into the professional firmware, klipper, or even the stock firmware. Creality released the source code of S1 Pro.

Use the S1 Pro firmware. Creality released the S1 Pro firmware. I used this to configure my own firmware for my S1+. The downside of this is it is based on Marlin 2.0.8 and Creality only released the 2.0.8.24. so yeah, this is not the latest firmware since the latest one is 2.0.8.26. A thing to note here, the released S1 Pro firmware has some error in it. You might want to check the pull requests to see the fixes for those errors.

If you're talking about buck converter, I don't see why not. Again, the ideal solution is for the firmware to handle the software PWM for that pin. Klipper does it well already so if you're using klipper or sonic pad, you should be able to just change it through software. If you're using the "professional" or stock firmware, you would need to reduce the speed on the hardware side. I think this is a bug on Marlin based firmware. That's why I only used a resistor, since it's small, cheap, and easy to remove if ever Marlin or Creality fixes this bug. I tried fixing it myself but didn't get that far. If you're interested, here's the issue I posted in Creality's github.

The tricky part for upgrading the heat block is the firmware. If you have the STM32F401 chip, I don't really see any reason why you can't just flash the S1 pro firmware to your S1. I may be missing something so I DO NOT recommend you doing that. Good news, Creality released the S1 firmware. Bad news is, it is still 3.0.3. So it is not the latest firmware. If you are comfortable with building your own firmware, I think this is the cheapest alternative than getting sonic pad. I did this route for my S1 Plus since they also released the S1 Pro firmware which I just edited to work on my S1 Plus.

Here's the one from Creality. Just make sure you're in the s1_pro branch. That branch is broken. so what I would suggest is to create a fork and apply the fix that Pethical made. Let me know if you have any questions about firmware.

hahaha. sorry. but if you're interested, here's the source code for the S1 Pro. The reason why I went this route is because I feel it's kind of a waste of money to not be using the touch screen and buying either the E3V2, sonic pad, or a raspberry pi for klipper. I got nothing to do with the touch screen at that point. so I try to use the stock firmware as much as I could. And yeah. so far it's been good. I was able to put some upgrades that needed some firmware updates.

There is _a lot_ wrong with Marlin. It is a complex codebase, full with ancient artefacts, litterred with preprocessor ifdefs every 2-3 lines of code, dynamic includes in the middle of CPP files, etc[1]. It's about as unreadable as C++ code gets--well, I guess it's not template metaprogramming.

Klipper by contrast is a breeze to read through[2].

I am very grateful for Marlin, for all of reprap, and everyone who has contributed to it. But saying there is nothing wrong with it is straight up misguided.

[1]: https://github.com/MarlinFirmware/Marlin/blob/bugfix-2.1.x/M...

[2]: https://github.com/Klipper3d/klipper/blob/master/src/lcd_hd4...

I think you are mistaken. I can't speak for implementations preceding the Ender 3 V2, so what you're saying may have been true at some point for other machines. However, here you can see Marlin developers confirm that there is an EEPROM on the stock E2V2 board using diagrams from Creality and photographic confirmation. Here is the datasheet for the EEPROM. Here is a thread discussing this Marlin release, and also the then-recent release of official Creality firmware which resolved the same issue. Since the stock firmware is based on Marlin, and at the time Marlin did not support this type of EEPROM, the EEPROM was not usable at launch. Any mainstream firmware (official or third-party) from the last three years will be using the onboard EEPROM unless the user intentionally specified otherwise.

pull latest Marlin from github: https://github.com/MarlinFirmware/Marlin

Also, checked the following discussion but seems like I need to update the firmware to be able to comment that like right? Temperature variance monitor tweaks by zeleps · Pull Request #23571 · MarlinFirmware/Marlin · GitHub

i spent some time and successfully rebased Kobra 2.8.2 OG firmware from an unknown Marlin ~2.0.8 frankenstein to a clean latest (as of now) release (not bugfix) 2.1.x -- v2.1.2.1 + 1 commit

As an example, check the macropocalypse in Marlin - but the actual trigger for me to start was Reprap firmware doing a floating point divide in interrupt context while targeting AVR8 core…

Any change of thermistor or to a PT100/PT1000 will require recompiling the firmware, because every type has different characteristics. Marlin uses an internal table to calculate the temperature for whatever reading it gets from the CPU's analogue-to-digital converter. It has many tables for different thermistors, but only one is ever incorporated at compile time. So you have to specify which type you're using. You can see the commonly-used types in the list in Marlin's Configuration.h file, in the section headed // @section temperature. The tables themselves are in Marlin/src/module/thermistor.

FWIW It IS open source but the GNU General Public License v3.0 rules apply. https://github.com/MarlinFirmware/Marlin/blob/bugfix-2.1.x/LICENSE