IO_PWM_DAC addition

[AbsoluteCatalyst]

Hi! Hope all's been well. Happy new year!

I've added this module to control the DAC's on our boards if available. (STM32F1 and AVR don't have DAC.) All HAL's now have: initHardwareDAC(fast8_t dacPin) & setHardwareDAC(fast8_t id, fast8_t value).

I avoided making initHardwarePWM automatically turn on the DAC for safety/"unexpected surprises" reasons.

example of new IO_PWM macros: IO_PWM_DAC(LaserDAC0, DAC0) IO_PWM_DAC(LaserDAC1, DAC1)

Due pins are: DAC0 (67) & DAC1(68)

STM32F4 (RUMBA32) pins are: PA_4 & PA_5 (note: PA_5 is used as EXP2's SPI SCK. Users will have to choose.)

SAMD51 (AGC) pins are: DAC0 (A0) & DAC1 (A1)

[repetier]

Yes, all is well.

Just also merged my modifications for AVR processor since there were quite a lot of small bugs and problems to solve for AVR. As it looks the main problem with AVR will be RAM memory usage. My simple case with RAMPS and 20x4 display already uses 7215 when I reduce to 16 move buffers and also after optimizing some cases. So no idea how to fit graphic displays. Main problem is that we store all data in RAM to be flexible and also need some extra memory to store eeprom positions due to flexible design. This easily adds to ram usage. This was also the time when I learned how PlatformIO can show your ram (.bss) memory usage with the inspect task. Really great. Around 3kb for move buffers, 759 byte for sd card and 520 byte per serial. Makes already 4,5kb and around 1kb is needed for stack so leaves 3,5kb for all devices, display, ...

Apart from this it already works also all moves have a long delay so there must something wrong in delay handling. But when they start to move it works good.

Another problem was that the AVR compiler is old and has bad C++ support with missing libraries. So some nice C++ solution needed a extra AVR solution.

Not really sure how I should proceed with it. Guess I make it work so we have basic support e.g. without display. But not everything that worked on V1 will be possible in V2 with AVR.

[AbsoluteCatalyst]

Hm. Have you ever seen the ETL library? I gave compiling AVR a shot last month and I used this library to fix the C++ compatibility. It seemed pretty neat. It's on PIO as a library too. lib_deps = etlcpp/Embedded Template Library @ 19.3.5

I couldn't finish compiling RAMPs though. Brick wall of linker/include issues right at the end that I couldn't figure out. I'm not too familiar with AVR.

Can you try adding the -flto build flag and see if compiles with avr-gcc, out of curiosity? It might help, maybe. It frees up a small percentage of Flash & RAM on my E3.

I'll give RAMPs another shot with your changes soon. I think it might still be worth supporting it.

[repetier]

ETL looks interesting, but at the moment not needed. Could fix all C++ problems by using C function or some #if cases for now. Should only add if there is a real need to keep dependencies low.

With my last commit you should also be able to compile avr code without problems. What is missing is hardware interrupt I think and I need to check analog handling and hardware pwm or I drop it like it was dropped in V1. Still have software PWM.

-flto unfortunately did not give me a byte of ram. But I can live with limited AVR support. We still have V1 and how wants a better printer control should upgrade to 32 bit anyway.