56c42b572c
and saving ~1k memory by limiting the `#pragma GCC optimize (3)` optimisation to `ultralcd_st7920_u8glib_rrd.h`. These optimisation was and is not done for all the other displays, is the reason for the big additionally use of memory, because the complete 'ultralcd.cpp' and 'dogm_lcd_implementation.h' was optimised (sadly i did not observe a change in speed). Unrolling the loop in `ST7920_SWSPI_SND_8BIT()`, what i expected the optimiser to do, by hand, saved some speed by eliminating the loop variable (i) compares and increases. Every CPU cycle in this loop costs at least 0.5ms per display update because it's executed more than 1k times/s. The delays are now pre-filled with the calculated values for 4.5V driven ST7920. A way to simply add __your__ timing into the configuration was made. At 4.5V 1.) The CLK signal needs to be at least 200ns high and 200ns low. 2.) The DAT pin needs to be set at least 40ns before CLK goes high and must stay at this value until 40ns after CLK went high. A nop takes one processor cycle. For 16MHz one nop lasts 62.5ns. For 20MHz one not lasts 50ns. To fulfill condition 1.) we need 200/62.5 = 3.2 => 4 cycles (200/50 = 4 => 4). For the low phase, setting the pin takes much longer. For the high phase we (theoretically) have to throw in 2 nops, because changing the CLK takes only 2 cycles. Condition 2.) is always fulfilled because the processor needs two cycles (100 - 125ns) for switching the CLK pin. Needs tests and feedback. Especially i cant test 20MHz, 3DRAG and displays supplied wit less than 5V. Are the delays right? Please experiment with longer or shorter delays. And give feedback. Already tested are 5 displays with 4.9V - 5.1V at 16MHz where no delays are needed. |
||
|---|---|---|
| buildroot | ||
| Marlin | ||
| .gitignore | ||
| .travis.yml | ||
| LICENSE | ||
| README.md | ||
Marlin 3D Printer Firmware
Additional documentation can be found in The Marlin Wiki. Please test this firmware and inform us if it misbehaves in any way, volunteers are standing by!
Release Candidate -- Marlin 1.1.0-RCBugFix - 27 April 2016
Not for production use – use with caution!
You can download earlier versions of Marlin on the Releases page. (The latest "stable" release of Marlin is 1.0.2-1.)
You'll always find the latest Release Candidate in the "RC" branch. Bugs that we find in the current Release Candidate are patched in the "RCBugFix" branch, so during beta testing this is where you can always find the latest code on its way towards release.
Future development (Marlin 1.2 and beyond) takes place in the MarlinDev repository.
Recent Changes
-
RCBugFix
-
RC6 - 24 Apr 2016
- Completed support for CoreXY / CoreXZ in planner
- Changes to positioning behavior
- Various issues fixed. More details pending.
- Throw error if compiling with older versions (<1.60) of Arduino due to serious problems with outdated Arduino versions
- Please upgrade your IDE at least to Arduino 1.6.0. Thanks.
-
RC5 - 01 Apr 2016
- Warn if compiling with older versions (<1.50) of Arduino
- Fix various LCD menu issues
- Add formal support for MKSv1.3 and Sainsmart (RAMPS variants)
- Fix bugs in M104, M109, and M190
- Fix broken M404 command
- Fix issues with M23 and "Start SD Print"
- More output for M111
- Rename FILAMENT_SENSOR to FILAMENT_WIDTH_SENSOR
- Fix SD card bugs
- and a lot more
- see https://github.com/MarlinFirmware/Marlin/releases/tag/1.1.0-RC5 for details
-
RC4 - 24 Mar 2016
- Many lingering bugs and nagging issues addressed
- Improvements to LCD menus, CoreXY/CoreXZ, Delta, Bed Leveling, and more…
-
RC3 - 01 Dec 2015
- A number of language sensitive strings have been revised
- Formatting of the LCD display has been improved to handle negative coordinates better
- Various compiler-related issues have been corrected
-
RC2 - 29 Sep 2015
- File styling reverted
- LCD update frequency reduced
-
RC1 - 19 Sep 2015
- Published for testing
Submitting Patches
Proposed patches should be submitted as a Pull Request against the RCBugFix branch.
- Don't submit new feature proposals. The RCBugFix branch is for fixing bugs in existing features.
- Do submit questions and concerns. The "naive" question is often the one we forget to ask.
- Follow the proper coding style. Pull requests with styling errors will be delayed. See our Coding Standards page for more information.
RepRap.org Wiki Page
Credits
The current Marlin dev team consists of:
- Scott Lahteine [@thinkyhead] - English
- [@Wurstnase] - Deutsch, English
- F. Malpartida [@fmalpartida] - English, Spanish
- Jochen Groppe [@CONSULitAS] - Deutsch, English
- [@maverikou]
- Chris Palmer [@nophead]
- [@paclema]
- Edward Patel [@epatel] - Swedish, English
- Erik van der Zalm [@ErikZalm]
- David Braam [@daid]
- Bernhard Kubicek [@bkubicek]
- Roxanne Neufeld [@Roxy-3DPrintBoard] - English
More features have been added by:
- Alberto Cotronei [@MagoKimbra]
- Lampmaker,
- Bradley Feldman,
- and others...
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.