Sunday, August 24, 2008
Limits to growth
In which the narrator discovers the dangers of trying to do too many things at once with 8-bit Pic microcontrollers... read more
I had the same challenge with 18F series and SPI. In my case, the UART wanted to use the SPI but the 18F4331 had alternate pins that allowed using the SPI and UART at the same time.
I use mikroC for my firmware, and i'm running 92% full on RAM and 90% full on ROM with my current stuff. granted i've squeezed two PID loops, EEPROM read/write code, SPI interface, and all the usual IO.
I found most of my space usage is in stupid atof and string outout routines, but i'm too lazy to write the code to covert from a PIC floating point to a pc floating point and back again so i just use strings, which is easy but sucks micro ram
I read some of your posts and others talking about having the reprap be more independent. At the end of the day, I ended up formulating a "it should be like a pc printer" model in my mind.
I think that means:
(1) there is some language the printer speaks that's lower level than the concerns the pc is dealing with. I favor gcode :)
(2) the printer controls all motion, not the host ( unlike reprap ). the host shouldnt be sending step/dir signals, or at least should not have to.
(3) its not necessary for the whole print job to fit in the controller
Links to this post: