forked from Palatis/arduino-softpwm
-
Notifications
You must be signed in to change notification settings - Fork 5
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
This greatly simplifies the code and reduces the compile size.
- Loading branch information
Showing
1 changed file
with
2 additions
and
6 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
5104017
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the original "intention" for using while loop instead of delay() or delayMicroseconds() is to demostrate that the SoftPWM library doesn't block the loop(), so users can run their own codes.
but assume every arduino players SHOULD know that delayMicroseconds() is a busy-waiting loop, these two should be considered equally instructive.
5104017
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Palatis thanks so much for taking a look at my code. I hope you don't mind that I have made some changes in my fork. If you see anything I've done you would be interested in merging to your repository I'd be happy to submit a pull request. I have been meaning to do one for my
SOFTPWM_DEFINE_PINn_CHANNEL()
macros.Regarding the changes to the example, my goal was to make a simplified example that would provide the least opportunities to confuse a beginner, the softpwm version of the Blink sketch. I do think it would be a good idea to also add a non-blocking example sketch. I have added this to my to-do list: #4.
5104017
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't really want to merge those SOFTPWM_DEFINE_PINn_CHANNEL() macros, because there are just too many of them...
I mean, see, there're a dozen AVR variants out there... we would make the macro list long like hell if we're going to support, say, 5~10 of them.
however I do get inspired by some of your codes, and may apply some of them to my own codebase if you don't mind.
but since I'm busy on some other things that may take some time to happen.
5104017
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand. My goal was to make it easy for the average Arduino user to use your library without having to look at a datasheet. For that purpose I think only ATmega328P, ATmega32U4, and ATmega2560 are needed. Anyone using a different AVR will be knowledgeable enough to use
SOFTPWM_DEFINE_CHANNEL()
. I ended up going overboard by adding support for all the ATmega1284P pinouts. I hadn't realized there were so many before I started. It's not a very good system but I haven't been able to come up with anything better for defining the channels using Arduino pin numbers.I'm very happy to hear that! As I said, if you want me to submit a pull request for any feature just let me know, I'd be happy to do so. Thanks so much for writing this excellent library. I've tried all the soft PWM code I could find and yours is best by far. I was just starting with Arduino when I first using the library so I wanted to use that perspective to attempt to make it more accessible to beginners.
5104017
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah I tried every SoftPWM libraries before I started this one.
all of them use some kind of loop to iterate through PWM channels, and rely on the
port_to_output_PGM
,port_to_mode_PGM
,digital_pin_to_bit_mask_PGM
PROGMEM arrays, and doesn't generate "good enough asm" (compared to my hand-cranked ones).the problem with those *_PGM array is that the compiler tends to deference them at run time (instead of compile time), thus introduce lots of overheads (~250% compared to mine).
I actually did a
gcc -E
to see if they actually output the asm I wanted, and my library generates 4 asm instructions per channel (5 if the shift-by-one is used)...