-
-
Notifications
You must be signed in to change notification settings - Fork 283
CurieSoftwareSerial Improvements #101
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
rxPin = _receivePin; | ||
_rxPin = _receivePin; | ||
rxIntraBitDelay = _rx_delay_intrabit; | ||
rxCenteringDelay = _rx_delay_centering; |
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.
Is there a good reason for defining any global variables here? This essentially makes all of these variables "reserved words" for anyone who includes this library in their sketch.
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 reason I used globals is because recv() which acts as the interrupt handler is static.
Therefore, it cannot access those variables if I kept them as member variables of the class.
Do you think having those variables names "reserved" can be an issue? If so I can always rename them to something else.
Also if you have a better solution, Pull Requests are always welcome. :)
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.
If they are internal and only to be used inside the library, the convention is to precede name with _ character
Also if you made them static then scope is limited to the file they are defined in.
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.
just make them static.
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.
One other way, equally not pretty, to allow static ISR routine to access variable of an object is,
- Define the ISR as private in a Class.
- Instantiate a static object of the Class.
- Define a static function, ISR_wrapper, that the sole purpose is to call the ISR of the Class via the static object.
The only advantage here is that the ISR is now free to access all variables in the Class without making them global, static, etc.
Using an unnamed namespace may also work (but I haven't tried this within an ISR that could be a limitation). Wrap all of the global variables (and it also works for functions) with: namespace {
// declare your variables here
// ...
} The compiler will create a unique namespace. There is nothing else you'd need to change. Here's an article that explains this approach: http://www.comeaucomputing.com/techtalk/#nostatic |
Mmm... May be not. ISR is not the direct cause. The fact that the ISR has to be declared as a static routine and it needs to access data/variables in a class that has not been instantiated, the compiler get upset. Static function can only access static variable... |
-changed global variables into static -allow different baud rates for different instances of a SoftwareSerial object -minor code cleanup of unused code -moved source code into src directory
@calvinatintel Looks good. All global are static. |
Cherry-picked |
-renamed global variable rxPin to _rxPin
-allow different baud rates for different instances of a SoftwareSerial object
-minor code cleanup of unused code