c0920bbf6a
* split tft folder in two: tft for color ui; tft_io for shared tft code * after the files got moved, now the code was moved to the right place * classic ui using TFT IO init lcd codes * feature to compile tft_io when enabled * compiling fix * lvgl spi tft working with tft io init codes * there is no need for separeted fsmc and spi class in lvgl anymore, as tft io handle everything * remove debug * base for TFT rotation and mirroring API, and ILI9488 support * ST7796S rotate and mirror support * ST7789V rotate and mirror support * ST7735 rotate and mirror support * ILI9341 rotate and mirror support * ILI9328 rotate and mirror support * R61505 rotate and mirror support * MKS TFT definitions * more configs for mks tfts * update config * naming typo * to configure the user interface * ANYCUBIC_TFT35 * tft configs * support for SSD1963 * tft display types * updated conditionals lcd; first board fully working with the new code - all 3 ui! * compatiblity * changed name * move classic ui file name * rename TURN -> ROTATE * GRAPHICAL_TFT_ROTATE_180 deprecated * first fsmc board fully working - chitu v5 * mks robin nano v1.2 + tft 35 ok! * right pin name * anycubic tft tested in a TRIGORILLA_PRO * chitu v6 * nano 32 tft orientation * mks tft43 * mks tft43 rotation * fixed LONGER LK tft setup * GRAPHICAL_TFT_UPSCALE defined by the display type * better offsets defaults * Update Configuration.h * Update tft_fsmc.cpp * Update Conditionals_LCD.h * Tweak comments * update nano tests * Revert "update nano tests" This reverts commit a071ebbfad30e28855a4a5695ec8a726542a1a65. * default tft * outdated comments * to not break non-vscode builds * upscale tft 35 * support tft 180 rotation for color ui * Each TFT Driver is responsible for its default color mode. * use auto detect in mks displays, because some of them could be shipped with diferent drivers * extra s * unused code * wrong -1 * missing mirror options * Smaller regex pattern * Comment updates * Clean up old defines * Apply pins formatting * GRAPHICAL_TFT_ROTATE_180 => TFT_ROTATE_180 * MKS_ROBIN_TFT_V1_1R * merge fix * correct resolution * auto is default, dont need be there, and it will allow the user to configure it even for named displays * to not use rotation with MKS_ROBIN_TFT_V1_1R * i like () in macros * avoid sleepy commits * default for st7789 is rgb * nano follow up * to allow ili9328 rotation * default is rgb * boards merge follow up * to match bootloader orientation * HAS_TOUCH_XPT2046 is not hal specific anymore * lets not forget LPC * 180 rotation for ili9328 and R61505 * Clean up whitespace Co-authored-by: Scott Lahteine <thinkyhead@users.noreply.github.com> Co-authored-by: Scott Lahteine <github@thinkyhead.com> |
||
|---|---|---|
| .github | ||
| buildroot | ||
| config | ||
| data/www | ||
| docs | ||
| Marlin | ||
| .editorconfig | ||
| .gitattributes | ||
| .gitignore | ||
| LICENSE | ||
| platformio.ini | ||
| process-palette.json | ||
| README.md | ||
Marlin 3D Printer Firmware
Additional documentation can be found at the Marlin Home Page. Please test this firmware and let us know if it misbehaves in any way. Volunteers are standing by!
Marlin 2.0 Bugfix Branch
Not for production use. Use with caution!
Marlin 2.0 takes this popular RepRap firmware to the next level by adding support for much faster 32-bit and ARM-based boards while improving support for 8-bit AVR boards. Read about Marlin's decision to use a "Hardware Abstraction Layer" below.
This branch is for patches to the latest 2.0.x release version. Periodically this branch will form the basis for the next minor 2.0.x release.
Download earlier versions of Marlin on the Releases page.
Building Marlin 2.0
To build Marlin 2.0 you'll need Arduino IDE 1.8.8 or newer or PlatformIO. We've posted detailed instructions on Building Marlin with Arduino and Building Marlin with PlatformIO for ReArm (which applies well to other 32-bit boards).
Hardware Abstraction Layer (HAL)
Marlin 2.0 introduces a layer of abstraction so that all the existing high-level code can be built for 32-bit platforms while still retaining full 8-bit AVR compatibility. Retaining AVR compatibility and a single code-base is important to us, because we want to make sure that features and patches get as much testing and attention as possible, and that all platforms always benefit from the latest improvements.
Current HALs
AVR (8-bit)
| board | processor | speed | flash | sram | logic | fpu |
|---|---|---|---|---|---|---|
| Arduino AVR | ATmega, ATTiny, etc. | 16-20MHz | 64-256k | 2-16k | 5V | no |
DUE
| boards | processor | speed | flash | sram | logic | fpu |
|---|---|---|---|---|---|---|
| Arduino Due, RAMPS-FD, etc. | SAM3X8E ARM-Cortex M3 | 84MHz | 512k | 64+32k | 3.3V | no |
ESP32
| board | processor | speed | flash | sram | logic | fpu |
|---|---|---|---|---|---|---|
| ESP32 | Tensilica Xtensa LX6 | 240MHz | --- | --- | 3.3V | --- |
LPC1768 / LPC1769
| boards | processor | speed | flash | sram | logic | fpu |
|---|---|---|---|---|---|---|
| Re-ARM | LPC1768 ARM-Cortex M3 | 100MHz | 512k | 32+16+16k | 3.3-5V | no |
| MKS SBASE | LPC1768 ARM-Cortex M3 | 100MHz | 512k | 32+16+16k | 3.3-5V | no |
| Selena Compact | LPC1768 ARM-Cortex M3 | 100MHz | 512k | 32+16+16k | 3.3-5V | no |
| Azteeg X5 GT | LPC1769 ARM-Cortex M3 | 120MHz | 512k | 32+16+16k | 3.3-5V | no |
| Smoothieboard | LPC1769 ARM-Cortex M3 | 120MHz | 512k | 64k | 3.3-5V | no |
SAMD51
| boards | processor | speed | flash | sram | logic | fpu |
|---|---|---|---|---|---|---|
| Adafruit Grand Central M4 | SAMD51P20A ARM-Cortex M4 | 120MHz | 1M | 256k | 3.3V | yes |
STM32F1
| boards | processor | speed | flash | sram | logic | fpu |
|---|---|---|---|---|---|---|
| Arduino STM32 | STM32F1 ARM-Cortex M3 | 72MHz | 256-512k | 48-64k | 3.3V | no |
| Geeetech3D GTM32 | STM32F1 ARM-Cortex M3 | 72MHz | 256-512k | 48-64k | 3.3V | no |
STM32F4
| boards | processor | speed | flash | sram | logic | fpu |
|---|---|---|---|---|---|---|
| STEVAL-3DP001V1 | STM32F401VE Arm-Cortex M4 | 84MHz | 512k | 64+32k | 3.3-5V | yes |
Teensy++ 2.0
| boards | processor | speed | flash | sram | logic | fpu |
|---|---|---|---|---|---|---|
| Teensy++ 2.0 | AT90USB1286 | 16MHz | 128k | 8k | 5V | no |
Teensy 3.1 / 3.2
| boards | processor | speed | flash | sram | logic | fpu |
|---|---|---|---|---|---|---|
| Teensy 3.2 | MK20DX256VLH7 ARM-Cortex M4 | 72MHz | 256k | 32k | 3.3V-5V | yes |
Teensy 3.5 / 3.6
| boards | processor | speed | flash | sram | logic | fpu |
|---|---|---|---|---|---|---|
| Teensy 3.5 | MK64FX512VMD12 ARM-Cortex M4 | 120MHz | 512k | 192k | 3.3-5V | yes |
| Teensy 3.6 | MK66FX1M0VMD18 ARM-Cortex M4 | 180MHz | 1M | 256k | 3.3V | yes |
Teensy 4.0 / 4.1
| boards | processor | speed | flash | sram | logic | fpu |
|---|---|---|---|---|---|---|
| Teensy 4.0 | IMXRT1062DVL6A ARM-Cortex M7 | 600MHz | 1M | 2M | 3.3V | yes |
| Teensy 4.1 | IMXRT1062DVJ6A ARM-Cortex M7 | 600MHz | 1M | 2M | 3.3V | yes |
Submitting Patches
Proposed patches should be submitted as a Pull Request against the (bugfix-2.0.x) branch.
- This branch is for fixing bugs and integrating any new features for the duration of the Marlin 2.0.x life-cycle.
- Follow the Coding Standards to gain points with the maintainers.
- Please submit your questions and concerns to the Issue Queue.
RepRap.org Wiki Page
Credits
The current Marlin dev team consists of:
- Scott Lahteine [@thinkyhead] - USA Donate / Flattr:
- Roxanne Neufeld [@Roxy-3D] - USA
- Chris Pepper [@p3p] - UK
- Bob Kuhn [@Bob-the-Kuhn] - USA
- João Brazio [@jbrazio] - Portugal
- Erik van der Zalm [@ErikZalm] - Netherlands
License
Marlin is published under the GPL license because we believe in open development. The GPL comes with both rights and obligations. Whether you use Marlin firmware as the driver for your open or closed-source product, you must keep Marlin open, and you must provide your compatible Marlin source code to end users upon request. The most straightforward way to comply with the Marlin license is to make a fork of Marlin on Github, perform your modifications, and direct users to your modified fork.
While we can't prevent the use of this code in products (3D printers, CNC, etc.) that are closed source or crippled by a patent, we would prefer that you choose another firmware or, better yet, make your own.