Skip to content
Snippets Groups Projects
  1. Aug 03, 2015
  2. Jul 31, 2015
  3. May 18, 2015
  4. Apr 13, 2015
  5. Mar 02, 2015
    • Scott Lahteine's avatar
      Cleanup of cardreader.* · f171656f
      Scott Lahteine authored
      - Apply standards to cardreader.*
      - Fix minor issues with cardreader.cpp
      - Apply standards to some other stale regions
      f171656f
  6. Jan 24, 2015
  7. Dec 18, 2014
  8. Dec 17, 2014
  9. Dec 13, 2014
  10. Dec 06, 2014
  11. Dec 01, 2014
    • Scott Lahteine's avatar
      # This is a combination of 4 commits. · de725bd4
      Scott Lahteine authored
      # The first commit's message is:
      SD Card Alpha Sorting
      
      First iteration of alphabetical sorting for SD cards, both
      slow+efficient and fast+rammy. Option for folders to sort first, last,
      or not at all.
      
      # This is the 2nd commit message:
      
      Expand on More RAM concept, address minor bugs
      
      # This is the 3rd commit message:
      
      Improvements, more SORT_USES_MORE_RAM
      
      With this option, always keeps the dir in RAM, doubling as a cache for
      getfilename. A board with only 8K of SRAM is cutting it very close.
      
      # This is the 4th commit message:
      
      Completed SORT_USES_MORE_RAM implementation
      
      For the MORE_RAM option we need to buffer both the short and long
      names, even though long names are sometimes redundant. Worst case, all
      the names are max length. We can save some RAM by not storing these. We
      could save more RAM by only storing the visible part of the long name.
      de725bd4
  12. Nov 27, 2014
    • Scott Lahteine's avatar
      Completed SORT_USES_MORE_RAM implementation · 8ebefe6d
      Scott Lahteine authored
      For the MORE_RAM option we need to buffer both the short and long
      names, even though long names are sometimes redundant. Worst case, all
      the names are max length. We can save some RAM by not storing these. We
      could save more RAM by only storing the visible part of the long name.
      8ebefe6d
    • Scott Lahteine's avatar
      Improvements, more SORT_USES_MORE_RAM · 725ba8d0
      Scott Lahteine authored
      With this option, always keeps the dir in RAM, doubling as a cache for
      getfilename. A board with only 8K of SRAM is cutting it very close.
      725ba8d0
    • Scott Lahteine's avatar
      SD Card Alpha Sorting · 14187dae
      Scott Lahteine authored
      First iteration of alphabetical sorting for SD cards, both
      slow+efficient and fast+rammy. Option for folders to sort first, last,
      or not at all.
      14187dae
  13. Nov 26, 2014
    • Scott Lahteine's avatar
      Completed SORT_USES_MORE_RAM implementation · eaa788e0
      Scott Lahteine authored
      For the MORE_RAM option we need to buffer both the short and long
      names, even though long names are sometimes redundant. Worst case, all
      the names are max length. We can save some RAM by not storing these. We
      could save more RAM by only storing the visible part of the long name.
      eaa788e0
    • Scott Lahteine's avatar
      Improvements, more SORT_USES_MORE_RAM · 69014455
      Scott Lahteine authored
      With this option, always keeps the dir in RAM, doubling as a cache for
      getfilename. A board with only 8K of SRAM is cutting it very close.
      69014455
  14. Nov 24, 2014
    • Scott Lahteine's avatar
      SD Card Alpha Sorting · f40cff59
      Scott Lahteine authored
      First iteration of alphabetical sorting for SD cards, both
      slow+efficient and fast+rammy. Option for folders to sort first, last,
      or not at all.
      f40cff59
  15. Oct 22, 2013
    • bkubicek's avatar
      preparation for hibernation · 39d88bcc
      bkubicek authored
      If a print is stopped, it would be nice in the future to write a file with the printer state, the filename of the print, and the position within the print.
      this file could be read, to continue a previously stopped print.
      not finished yet.
      39d88bcc
    • bkubicek's avatar
      Sub-file calls. · ab965376
      bkubicek authored
      by overloading M32 it is now possible to execute gcode files from other gcode files, with a fixed recursion level.
      This can be used e.g. for having a real start.g and end.g somewhere on the sd card, which are then called from the normal print file.
      Another usecase would be to have macro-files for nozzle-change and layerchange.
      I have not tested the speedwise performance. The testing was done with pronterface.
      
      syntax:
      normal call from sd card will open the new file and continue executing there.
      M32 !/path/filename#
      this however will call the new file and return to the caller file.
      M32 P !/path/filename#
      with the optional "S<position>" the  file starting position can be set.
      this is for continuing prints from a previous location.
      ab965376
  16. May 04, 2013
  17. Mar 31, 2013
  18. Dec 12, 2012
  19. Dec 03, 2012
  20. Aug 22, 2012
  21. Jun 02, 2012
  22. Mar 19, 2012
    • Bernhard's avatar
      found error in filenames. · 15322004
      Bernhard authored
      One array was too short. This had nothing to do with long filenames, other than if they were 12 characters exactly, which could only happen if the extension and the text before were filled completely
      15322004
  23. Mar 03, 2012
  24. Feb 29, 2012
  25. Dec 26, 2011
  26. Dec 09, 2011
Loading