Open Traumflug opened 9 years ago
Traumflug
commented
9 years ago Fine. Forwarded all this to the experimental branch, so it's official now. Removed the sdcard4 branch yet again. Also picked the few remaining nuggets from branches sdcard, sdcard2 and sdcard3 into a new branch sdcard-todo and removed these, too.
Traumflug
commented
9 years ago @phord, do you still have plans with the issue-104 branch? I think the plan is good, but the advantage compared to the cost (triple all the parsing structures) is small.
Nevertheless I rebased this branch close to the experimental branch and did my best to not break anything, so you could continue working on it. If you think that's pointless, I'd move this branch as a patch to attic/, where some older but good ideas are collected.
phord
commented
9 years ago I quite forgot I did this. :-) I was in China adjusting to jet lag at the time. I will go revisit this and see if I can make it more palatable.
phord
commented
9 years ago Fixed some breakages in 37de38d4b22234a8e6339ca83a2eafba6c7f1f33, but the code is still borked because it doesn't manage state changes between different input streams.
The good news is even with all these changes it adds only about 30 bytes to the binary, currently.
youssefaly97
commented
9 years ago I'm back for more testing, I got myself delayed because I burnt the usb to serial converter on the arduino board. Now it's up and running as well as I got a proper SD card/LCD/Encoder/Buzzer smart controller board for the ramps (from reprapdiscount.com) so I can do better/more reliable testing.
Great job everybody !
On Jul 9, 2015, at 1:21 AM, Phil Hord notifications@github.com wrote:
Fixed some breakages in 37de38d, but the code is still borked because it doesn't manage state changes between different input streams.
The good news is even with all these changes it adds only about 30 bytes to the binary, currently.
— Reply to this email directly or view it on GitHub.
Traumflug
commented
9 years ago The good news is even with all these changes it adds only about 30 bytes to the binary, currently.
That's indeed good. Much more might not be justifyable, because the only advantage I see so far is, that typing an incomplete command on serial doesn't stop reading from SD card.
Currently I'm changing the implementation to not read into a buffer, but to send the characters right to the parser while reading from the card. Will be sd_read_gcode_line(), no further changes to the parser required.
Traumflug
commented
9 years ago I've just pushed a new branch sdcard (not to be confused with the old one), which implements bufferless reading from SD card. Instead of reading chunks of 16 bytes from the card byte by byte into the buffer, then reading this buffer yet again byte by byte for parsing, G-code is now parsed immediately as it's read from the card. Gladly we have a parser which allows this.
This got rid of the buffer and its RAM usage and increased read performance by factor four. G-code can be read now at a rate of almost 23'000 bytes/second or 350 lines/second with conservative SPI settings. That's a full megabyte in just 46 seconds. Unfortunately it also adds 68 bytes binary size, but I think that's worth it.
Traumflug
commented
9 years ago As just notified in another discussion, I rebased issue-104 onto current experimental after picking most commits from there.
If you pull regularly, you might have noticed a new sdcard2 branch. This is for implementing handling an SD card. I reviewed and wrote the code carefully, but I have no such hardware, so I rely on your testing.
Other than the 3.5 years old(!) sdcard branch it uses not FatFs, but Petit FatFs. This didn't exist back in 2011 and is a slimmed down version of FatFs. Slimmed down, like it can't handle file metadata and can handle one file at a time only, which is entirely sufficient for our needs.
Current status is, M21 - M25 implemented, so you should be able to open an existing file and print from it. To enable this stuff, define something like this in your config.h:
The latter only if you actually have a SD card detect pin. Pin names have to match your actual hardware, of course.
The only supported filesystem is currently FAT16. Expanding to also FAT12 and FAT32 shouldn't be difficult, there are flags in pff_conf.h. Implementing file writing will be a bit more difficult, but I guess I'll do that as soon as reading is known to work.
The nice thing is, all this stuff currently chimes in at only 3156 bytes, so Teacup still easily fits into ATmega 328's. Not defining a select pin entirely removes all the SD card support, not a single extra byte if you don't need such stuff.