Configuring Marlin for a 328

Everything so far has been relatively straight forward, until I got to re-defining the pin outs for my 328 set up.

I use analog 2,3 as digital outs for my extruder step/dir, but I use digital 2,3 as my X step/dir.

In the pins.h file, there does not appear to be a way to differentiate between the analog and digital pins. Am I missing something, or is there no way to use the analog pins as digital outs in this firmware?

If you look at the pin map for the 168 in pin.h you will see that the A0 - A5 are also called D14 - D19 so all you need to do is use the D number instead.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

Ahh, thanks. Apparently there are some other issues as well, but Erik van der Zalm is sending me a modified version that might run alright.

Marlin uses too much ram to be used on a 328. Even with the move queue at 2.

Erik seems to think he can make it work, and as he created Marlin i'm inclined to believe him.

It should work on a 328 as GRBl is where the look ahead comes from and its made to work on 168's and 328's specifically. [dank.bengler.no]

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

You guys can believe what you want. The grbl code isn't the issue. Sprinter is very inefficient with ram. The strings aren't even in flash.

It's starting to work

Erik has got it to the point where I can jog it through pronterface without issue. I've even run some files through it with some success. Yes, it does still freeze up after a bit, but I don't think it is all that far from working properly.

JV4779, He's actually been moving parts of it into flash to free up more ram, so there may be more hope than you think

I never meant to imply that it was impossible to make Marlin work on a 328. Just the current release will not work because the raw ram requirements, even with a minimal (ie useless) move buffer, are just too high.

That's fair then.

Did anyone ever get this to at least compile?
I'm interested in getting Marlin working on a 328p, and am having a lot of issues.

I have had no luck getting Marlin to compile. Lots of errors, and deep in the hardwareserial.cpp, etc.

---

David

-------------------------------------------------------------------------------------------------------------------------------------------------

MakeMendel Orca v0.3, Gen6 with 5D, Slic3r. Usually 1.75mm with a modified V9 hot end and extruder.

Nope. Never got it to work. Even if it did i don't think the buffer would have been big enough to be useful.

---

www.Fablicator.com

I'm going to give it a try.arduino 1.0 has the ability to convert strings into flash memory rather than taking up ram space.. another thing i got working with sprinter was combining the dir pins into 1 dir pin. also running at 8mhz with internal clock frees up an additional 2 pins. digitalwritefast recognizes these additional pins. one may ask why? it is easy to breadboard a 328 chip and to have room to add additional components for testing.

if I don't do updates in two weeks with it working on 328, then consider it a failure. I will then go back to sprinter with sd support. but i would rather marlin work on 328, even nearly crippled for the prusa i'm building below.




I have enough pins to also run lcd support, but i think marlin has that built in..

process_command seems to take over 20k of code. this seems incredibly huge. also rather than compare each char as a string why not compare it as a byte. this alone i think will shrink the process_command to 5k or less.. but then again we will see. this will be a serious rewrite.. that is if it works...

May I suggest to pick Marlin's look-ahead and put this into Teacup? Teacup is already small, well tested and has a command queue.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

And while you're at it... port marlin's implementation of Matthew Roberts advance algorithm...

lol!

I'll stick with trying to shrink marlin.. process_commands() is like the steering wheel of the car, look-ahead is like changing out the engine block.

OK I've trimmed down the fat a bit, but left the code in place it is just disabled if motherboard ==4 is selected in configuration.h

most mcodes above 115 except bed temp commands are not essential, so they are disabled with 328, also some strings that report at start up and the eeprom check when firmware initializes are disabled as well. eeprom is a separate memory, but the code is taxing to read and write it.

for example you wont be able to add a remote camera to take snap shots anymore if using 328... bummer.

some of the cautionary temp controls such as max and min temps are disabled, but may be enabled carefully based upon flash space available.


next is to find approximate but close fits for the acceleration tables that are in epprom, not using those tables along with the above, and some minor code changing allows the code now to take 30350 bytes. however i still need to create a simplified table, and continue finding ways to save space . also i have disabled pid, but will enable it if it fits when modifications are complete. with 8mhz arduino flash i have 30720 bytes to program with. also sd is disabled currently

Edited 2 time(s). Last edit at 03/02/2012 10:57AM by jamesdanielv.

You're getting closer and closer to Teacup. The tables can be calculated on the fly, see line 634 to 675 of this file: [github.com]

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Just came across the wiki page for r2c2 board and it says it uses a modified version of Teacup mixed with GRBL. I had a look at their github repo and what do you know it has Teacups Gcode processor and GRBL's look ahead plus a pile of stuff for Arm32. So maybe someone could strip the Arm32 parts and we could have Teacup with look ahead.

[github.com]

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

Interesting. I can't find the common branch point for the Teacup files in R2C2, though. Looks like it'll need to be a manual merge, but both branches have lots of changes.

Interesting indeed. In it's current state one wouldn't recognize the R2C2 firmware is derived from Teacup, but let's have a look how this looked earlier ...

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

marlin is unique GRBL because it changes speed of e axis in relation to how fast the stepper is going. look at stepper.c file in both location of marlin firmware and grbl. i don't know why this link was so hard for me to find earlier but it is here [github.com] for grbl

grbl on its own does nothing for compensation of e (the timer variable in stepper.c of merlin)

on another note here is marlin that sort of fits into 328. it fits but the ram used is nearly everything. i can get it to init thru the serial com in arduino ide, but the pronterface host does not see it. Marlin does report free ram at start up so that should help troubleshooting. if anyone wants to play with the code it is here. [www.useablesoftware.com]

with all that said. the 328 version does not compensate for e either, it is disabled to allow it to fit without the eprom table,

so that being said it is waiting for someone who can free up ram and give it a try.


I'm off to do other things now...


just to note the acceleration and path profile are located in planner.c planner.h in grbl and is called from stepper.c

Edited 1 time(s). Last edit at 03/04/2012 09:24AM by jamesdanielv.