PWM on TX pin?

[chupocro]

In your example you are generating PWM signal on 20 channels and one of them is PD1 which is TX pin so I expected garbage in the terminal but there wasn't any although I tried various serial speeds in both the firmware setting and the terminal setting :-/ How is that possible and how can Serial.print() work in the same time (and without any interference) with software PWM on TX pin?

BTW, it would be great if you added the fade in/out parameters as in the other one SoftPWM library. Fade out is useful not only for driving LEDs but for driving DC motors as well.

[Palatis]

1. fot the tx pin, i have no idea.......

2. for the fade-in/out/in-out/out-in/whatever, no. this lib will and always will only do one thing.

[Palatis]

i think the animation ahould be done separately.

[chupocro]

Yes, I agree the animation when using the library for LED strips should be done separately. However, the library could be very useful to drive small DC motors too (using the appropriate driver) where optional fade-out parameter could be used to run the motor with deceleration so it can stop nicely.

I'll further investigate why generating the PWM signal on TX pin doesn't break Serial.print() as I expected it would.

Thanks for the reply
Regards

[Palatis]

well for what I mean, this lib will focus on generating software PWM on pins, not altering PWM level values by itself.

the alternation of the PWM level (for whatever purpose) should be done separately in another lib.

codes inside the ISR should be as little as possible (both footprint-wise and time-wise), for those long-period and not-so-percise requirements, i'd rather leave them in loop().
ex. the "fade-out" for servo motors doesn't really break your application if it's 500ms or 501ms, similar for LEDs.

[chupocro]

Yes, generally ISR should be as fast as possible but there are always exceptions. For example I've years ago made an electronic device based od ATmega8 where complete code runs inside ISR and where there are even occasions when ISR routine takes more time than there is time between interrupts - which is something that generally should be avoided but I made that on purpose and I was counting T-states (cycles) after disassembling the code generated by the compiler and used oscilloscope to check all the timings one more time.

As for the driving DC motors and changing the duty cycles in a loop - yes that is one of the ways but I have to drive 9 DC motors plus make some calculations, parse the I2C messages and read the data from lookup tables at the same time so I had to put the code for changing the duty cycle inside the ISR. I based the software PWM code on AVR136 - Application Note for implementing Low-jitter Multi-channel Software PWM for AVR series microcontroller.