cskozlowski / mmu2

This arduino codebase is for an mmu2 home brew clone
GNU General Public License v3.0
73 stars 17 forks source link

Further reorganization and compatibility with Platformio #3

Closed KarlZeilhofer closed 5 years ago

KarlZeilhofer commented 5 years ago

Dear Chuck,

would you mind to try out and pull my further reorganizations?

I've introduced a compatibility layer with Platformio. It is still compatible with the Arduino IDE, without any modifications!

Further I used the F() macro, to keep all the strings for printing to the serial in the AVR's flash, to save RAM. In first place, the program didn't fit into the Arduino Leonardo at all!

Greets, Karl

cskozlowski commented 5 years ago

I hadn't tried this code in the Arduino Leonardo yet. I am glad to see you are forging ahead, please keep me posted on your progress. I also want to add some EEPROM() commands to track selector and filament position in case of a power failure. I should add those to my 'TODO' list.

KarlZeilhofer commented 5 years ago

I'm very, very happy, that you take my support.

Regarding EEPROM: I think it's a bad idea, to save such things in the EEPROM, since such a memory only lasts for 10k or 100k write cycles. An externally connected FRAM via I2C could help here. This are rather modern memory chips, which can last for at least a human lifetime, writing each second onto it. That's what you want to have. A quick search on ebay shows some results: https://www.ebay.at/sch/i.html?_from=R40&_trksid=p2380057.m570.l1313.TR12.TRC2.A0.H0.Xfram+arduino.TRS0&_nkw=fram+arduino&_sacat=0

But there they are not really cheap. On Digikey you could get cheaper ones, if you want to. They start from about 1€/chip.

What is the reason for saving positions?

cskozlowski commented 5 years ago

I would only save the current position (filament, selector) to recover from a power failure - that would be the only good reason to use the EEPROM that I can think of. I'm aware of the write cycle limitation in EEPROM but hadn't thought about how many months/years until I reach the limit of write cycles.

Regarding using the arduiono Leonardo - I need to extract the hardware mapping (data pin I/O) to a separate *.h file to make it easier to work with other boards. Word of warning - I don't have any code that interacts with the buttons or LEDS on the current MMU2 clone or production board. In fact, I only use the serial port to see status at the current time and I was going to add a single button and a 4-line LED screen for status (easier to rig up than a bunch of LEDs and push bottons). Thoughts?

cskozlowski commented 5 years ago

General apology for my code state - it was written as I was developing so there are many sections of the code that represent the best of 'bad coding practices'. I know that 'goto' statements are bad form but I was being lazy.

KarlZeilhofer commented 5 years ago

do you expect side effects going from 16 bit signed ot 32 bit unsigned? The CPU needs a bit more time for manipulating them.

KarlZeilhofer commented 5 years ago

I don't mind your coding style. I assume, you are not a professional C programmer in your daily job. That's fine for me. I will fix that anyway. Prusa's devs published very much of bad styled code - as their professional work!

cskozlowski commented 5 years ago

Regarding going from 16 bit to 32 bit unsigned - you will be fine from a performance perspective.

I was a hardware designer using bit slice/microprocessors/DSPs for many years. I wrote more embedded code than I can remember - I will happily admit that my code isn't pretty but it works. My editor for programming was vi and emacs - these modern IDEs are pretty amazing.